lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D39EEDA.90902@xmsnet.nl>
Date:	Fri, 21 Jan 2011 21:38:50 +0100
From:	Hans de Bruin <jmdebruin@...net.nl>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Jesse Gross <jesse@...ira.com>, netdev <netdev@...r.kernel.org>
Subject: 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 :
>> 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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ