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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
