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

Hans de Bruin
2011-01-21T20:37:49Z

On 01/21/2011 08:55 PM, Eric Dumazet wrote:
> Le vendredi 21 janvier 2011 à 20:47 +0100, Hans de Bruin a écrit :
>> On 01/18/2011 11:03 PM, Eric Dumazet wrote:
>>> Le mardi 18 janvier 2011 à 22:42 +0100, Hans de Bruin a écrit :
>>>> On 01/18/2011 09:06 PM, Jesse Gross wrote:
>>
>> ...
>>
>>> 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