Fw: masquerading failure for at least icmp and tcp+sack on amd64
kaber at trash.net
Wed Sep 7 23:34:10 CEST 2005
Marc Lehmann wrote:
> I think I have the LOG target compiled into the kernel. After the echo, I got
> this within a matter of seconds:
> printk: 614 messages suppressed.
> ip_ct_tcp: bad TCP checksum IN= OUT= SRC=xxxxxxxxxxxx DST=22.214.171.124 LEN=105 TOS=0x00 PREC=0x00 TTL=53 ID=33989 DF PROTO=TCP SPT=119 DPT=41349 SEQ=495763142 ACK=177548929 WINDOW=56677 RES=0x00 ACK PSH URGP=0 OPT (0101080A0986EF9D00E16123)
Interesting .. if this isn't real there is most likely some problem with
HW checksumming in netfilter. What does ethtool -k <dev> show?
> This is interesting, as the connection in question seems to work fine (at
> least I can download news at 32kb/s, which is the rate limit on the other
> side without much more than 32kb/s on my ppp link, so it is weird that
> this many packets should have invalid tcp checksum. Maybe this is somehow
> I then tried to create a masqueraded connection and got the expected
> symptoms: correctly re-written packet leaves interface, return packet gets
> During that time, I got more of the above messages, but none related to the
> test connection.
Could be because of net_ratelimit() message surpressing.
> (As I wrote in another mail), I also found in the meantime that switching
> off SACK only results in a correct handshake, further packets might and
> usually will cause a RST.
I'm not aware of any special handling for SACKs that would make it fail,
especially considering that ICMP also fails, but I'm going to look into
>>>Kernels that don't work:
>>> 2.6.13-rc7 (compiled with gcc-3.4 and 4.0.2 debian), 2.6.13 (gcc-4.02)
>>Can you retest with 126.96.36.199 on 64bit so we can see if it is a new
> I hope that trying with 2.6.11, and getting the same problem (as I did in
> the meantime), is even better than testing 188.8.131.52.
Thanks, this is even more evidence for HW checksumming problems, these
existed for a long time.
>>So far I don't think its related to routed.
> The weird thing is that it works on tap, but not on ethernet/ppp. Maybe
> the kernel code gets some offset wrong?
Another sign pointing to HW checksumming ..
More information about the netfilter-devel