conntrack bug?

[Jason Stubbs <j.stubbs@linkthink.co.jp>]

Hi,

While testing patches for IPVS, I found a strange behaviour of conntrack that 
happens on an unpatched kernel too (2.6.24.4). Given the following rules:

iptables -A FORWARD -p tcp -d 192.168.1.3 --dport 80 \
                    -m state --state NEW -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P FORWARD DROP

And a network setup where replies from 192.168.1.3 don't go via the same 
machine - ie, they appear to be being dropped - the following conntrack entry 
appears when sending only an ACK packet to 192.168.1.3:

ipv4     2 tcp      6 431684 ESTABLISHED src=192.168.0.104 dst=192.168.1.3 
sport=12345 dport=80 packets=2 bytes=95 [UNREPLIED] src=192.168.1.3 
dst=192.168.0.104 sport=80 dport=12345 packets=0 bytes=0 mark=0 use=1

If a SYN has been sent the following state appears and no traffic (including 
an ACK) is allowed to pass:

ipv4     2 tcp      6 119 SYN_SENT src=192.168.0.104 dst=192.168.1.3 
sport=23456 dport=80 packets=1 bytes=50 [UNREPLIED] src=192.168.1.3 
dst=192.168.0.104 sport=80 dport=23456 packets=0 bytes=0 mark=0 use=1

I would think that behaviour to be correct, but an entry appearing when only 
an ACK packet has been sent seems wrong. Is it a bug or intentional?

-- 
Jason Stubbs <j.stubbs@linkthink.co.jp>
LINKTHINK INC.
東京都渋谷区桜ヶ丘町22-14 N.E.S S棟 3F
TEL 03-5728-4772  FAX 03-5728-4773
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html