[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.WNT.2.00.1101211414030.5816@JBRANDEB-DESK2.amr.corp.intel.com>
Date: Fri, 21 Jan 2011 14:15:49 -0800 (Pacific Standard Time)
From: "Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To: Hans de Bruin <jmdebruin@...net.nl>
cc: Eric Dumazet <eric.dumazet@...il.com>,
Jesse Gross <jesse@...ira.com>, netdev <netdev@...r.kernel.org>
Subject: Re: [regression] 2.6.37+ commit 0363466866d9.... breaks tcp ipv6
On Fri, 21 Jan 2011, Hans de Bruin wrote:
> > 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.
maybe you're still seeing confusing output on tx due to GSO, try turning
that off with ethtool -K ethX gso off
GSO still software-segments packets, and maybe the tap for tcpdump is
before GSO operation.
> > 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.
>
>
--
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