On 10.11.2010 18:37, Eric Dumazet wrote: > Le mercredi 10 novembre 2010 Ã 18:17 +0100, Jan Engelhardt a Ãcrit : >> On Wednesday 2010-11-10 17:44, Eric Dumazet wrote: >>> >>> [ 9920.234680] ipt_LOG: sk=ffff880118bd32c0 sk->sk_socket=ffff88011d0d8c00 file=ffff88011cd4e100 >>> [ 9920.234731] IN= OUT=eth1 SRC=192.168.20.108 DST=192.168.20.110 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=63704 DF PROTO=TCP SPT=60088 DPT=22 WINDOW=35 RES=0x00 ACK FIN URGP=0 UID=0 GID=0 >>> [ 9920.235221] ipt_LOG: sk=ffff880078998000 sk->sk_socket=ffff880078c58300 file= (null) >>> [ 9920.235271] IN= OUT=eth1 SRC=192.168.20.108 DST=192.168.20.110 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=60088 DPT=22 WINDOW=35 RES=0x00 ACK URGP=0 >>> >>> You can see in my log, that the last packet seems to be from a different >>> socket ! (sk pointer changed to ffff880078998000 !) >> >> Yes, that's it. >> >>> Well well well, thats an ACK, in answer to FIN packet received from remote >>> side. >> >> But why is it not handled by sk ffff880118bd32c0 anymore? >> It does have, after all, the same (addr,port) tuple. >> And it is sort of a hiccup for xt_owner users. > > Its because of TIMEWAIT state : no more socket > > We use a special tcp socket (net->ipv4.tcp_sock) in tcp_v4_send_ack() Yeah, this has always been a problem with the owner match. I don't think this fixable, it should probably only be used in a stateful manner. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
