Re: [regression] 2.6.37+ commit 0363466866d9.... breaks tcp ipv6

On 01/21/2011 08:55 PM, Eric Dumazet wrote:

Le vendredi 21 janvier 2011 à 20:47 +0100, Hans de Bruin a écrit :

quoted

On 01/18/2011 11:03 PM, Eric Dumazet wrote:

quoted

Le mardi 18 janvier 2011 à 22:42 +0100, Hans de Bruin a écrit :

quoted

On 01/18/2011 09:06 PM, Jesse Gross wrote:

...

quoted

You could try "tcpdump -i eth0 ip6 -v"

I guess you receive frames with bad checksums

While you where staring at the code, I was fooling around with tcpdump.
And while the problem is fixed, I still have some questions:

Is there tool which shows whether a nic supports ipv6 checksum offload
or not?

I have captured http traffic (wget http://bootes/) between psion (my git
tree following laptop) and bootes (something running 2.6.33.7).
Attached is a capture with psion running 2.6.37 and one with this
morning's git tree. Wat's with the 'chsum ... ( incorrect ->  ' lines ?
ifconfig does not show errors on either of the machines.

tcpdump gets a copy of outgoing frames before NIC performs tx checksum
(if tx checksum handled by NIC), so it's normal to have "bad checksums"
on TX, unless you disable tx offloading (ethtool -K eth0 tx off)

That seem reasonable but: the bug was triggered because my nic could not offload checksumming, so what's tx=on if there's no support for it? I have turned tx off and my tcpdump still shows bad checksums on outgoing tcp/ip6 packets. I have tried 2.6.36: bad checksums, 2.6.35 and surprise: good checksums with tx=on.

I was referring to check with tcpdump incoming frames, because invalid
checksums in RX is sign that other peer sent wrong checksums

Ok, thats clear, the receiving site is apparently a more reliable checksummer than the sending site.

-- 
Hans