From: Hans de Bruin <jmdebruin@xmsnet.nl>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Jesse Gross <jesse@nicira.com>, netdev <netdev@vger.kernel.org>
Subject: Re: [regression] 2.6.37+ commit 0363466866d9.... breaks tcp ipv6
Date: Fri, 21 Jan 2011 21:38:50 +0100 [thread overview]
Message-ID: <4D39EEDA.90902@xmsnet.nl> (raw)
In-Reply-To: <1295639745.2609.29.camel@edumazet-laptop>
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
next prev parent reply other threads:[~2011-01-21 20:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-16 20:24 Possible ipv6 regression Hans de Bruin
2011-01-18 19:52 ` [regression] 2.6.37+ commit 0363466866d9.... breaks tcp ipv6 Hans de Bruin
2011-01-18 20:06 ` Jesse Gross
2011-01-18 21:42 ` Hans de Bruin
2011-01-18 22:03 ` Eric Dumazet
2011-01-19 13:17 ` Hans de Bruin
2011-01-21 19:47 ` Hans de Bruin
2011-01-21 19:55 ` Eric Dumazet
2011-01-21 20:38 ` Hans de Bruin [this message]
2011-01-21 22:15 ` Brandeburg, Jesse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D39EEDA.90902@xmsnet.nl \
--to=jmdebruin@xmsnet.nl \
--cc=eric.dumazet@gmail.com \
--cc=jesse@nicira.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.