![](https://seccdn.libravatar.org/avatar/814f1c9f82898e057fe8d46a106381fd.jpg?s=120&d=mm&r=g)
On Dec 31 2006 14:51, Jan Engelhardt wrote:
WINDOW=8192 RES=0x00 ACK SYN URGP=0 OPT (02 04 05 98 01 01 08 0A 08 A2 DB AD 01 97 6D 81)
This however is strange. It would mean you got a spurious SYN ACK in your connection. Which can't be, since the connection is unknown (INVALID, see above). The option string says: maximum segment size is 0x598 (1432), and some other bits not covered by RFC 793.
Well, it's not so strange. Combining "INVALID" and "SYN ACK" means the SYN ACK returned _much_ later than the Linux TCP stack expected it (a minute, hour, day, no idea what the default is) -- unless of course the below holds true where connections spuriously become INVALID. The option string, fully decoded: 0x02040598 TCP MSS: 0x598 = 1432 0x01 noop 0x01 noop 0x080A.. Lifetime of orphaned FIN-WAIT-2 state; you can find details in /usr/src/linux/net/ipv4/tcp.c line 1643 ("This is a (useful) BSD violating of the RFC.").
All in all my conclusion is: The packet you received is valid, as part of _you_ establishing a connection (probably visiting a webpage with ads), however, for some __strange__ reason, the connection is INVALID.
I have seen similar strange things with iptables/netfilter recently -- established connections just went INVALID for no apparent reason, yet they continued to be listed as ESTABLISHED in `conntrack -L`.
What you can do in the short term: post the results of `iptables-save`, it might reveal some oddity I just stumbled over yesterday. In the long term, upgrading to iptables 1.3.7 (suser-jengelh) might solve the problem, the more if iptables-save shows what I think it could show.
-`J' -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org