Date: Thu, 25 Jan 2007 08:54:24 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Bill Paul <wpaul@FreeBSD.ORG> Cc: freebsd-current@FreeBSD.ORG, Rene Ladan <r.c.ladan@gmail.com> Subject: Re: Call for re(4) checksum offload testers. Message-ID: <20070124235424.GA41550@cdnetworks.co.kr> In-Reply-To: <20070124190203.E80FB16A403@hub.freebsd.org> References: <45B736DE.1000100@gmail.com> <20070124190203.E80FB16A403@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 24, 2007 at 07:02:03PM +0000, Bill Paul wrote: > > Bill Paul schreef: > > [...] > > > > > I'm very confused as to why the chip botches the TX checksumming in > > > this case. Unfortunately, most of this confusion stems from the fact > > > that you didn't specify exactly which chip rev the user with this > > > problem has, or give a test case to trip the bug. > > > > > I am that user, using this card, found in Asus A6JE laptops. From pciconf: > > > > card: class=0x020000 card=0x11f51043 chip=0x816810ec rev=0x01 hdr=0x00 > > vendor=Realtek Semiconductor > > device=RTL8168/8111 PCI-E Gigabit Ethernet NIC > > > > > I'm assuming this yet another problem with small IP fragments being > > > mangled. That being the case, it should be possible to trip the bug > > > with "ping -s 1473 <somehost>." (1473 is 1 byte too large to fit into > > > a 1500 byte frame, which will cause a 1 byte fragment to be sent.) > > > I thought I tested this with my sample PCIe cards though, and didn't > > > see a problem. I'll have to try it again tomorrow. > > > > > ping -s 1473 <NAT box> succeeds both with and without the patch (i.e. > > ping gives timings), I've included two tcpdumps for further analysis. > > Unfortunately, these packet dumps don't help me: I need a packet dump > that shows the failure, and these don't. > > > The bug is visible when logging in to sites such as gmail.com or > > nl.bol.com (a Dutch shopping site), or when connecting Thunderbird to > > pop.gmail.com (which uses POP3 with SSL) > > Hm. Ok, apparently the TCP segments that cause the problem look like > this: > > 10:41:54.607019 00:03:47:a6:3f:c0 > 00:00:0c:07:ac:2e, ethertype IPv4 (0x0800), > length 54: 147.11.46.221.63693 > 216.239.57.83.80: . ack 1 win 65535 > > I captured this by doing 'telnet gmail.com 80' from my system at work. > I contrived a quick test where I wrote a small routine to send a packet > with exactly these contents and duplicated the problem with my sample > 8111B/8168B card (the frame isn't mangled as badly as the small IP > fragment case, but the TCP checksum is wrong). The RTL8101E (10/100) PCIe > adapter also botches the checksum in the same way. The earlier PCI cards > do not. > > Based on testing with my sample adapters, I think the right thing to do > is skip the software padding in the TCP case. It appears that even > the older 8169 adapters that botch the small IP fragment case will correctly > handle this small TCP segment case. I'm attaching a patch which should > fix the problem without breaking the workaround for other NICs. If you > verify that this patch also fixes your problem, then this patch should > be checked in instead of the other one. > Since you have the problematic hardware in hand would you verify it works for small UDP case?(i.e. 28 bytes, IP header 20 bytes, UDP header 8 bytes). If you already checked UDP case please ignore this mail. Thank you. -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070124235424.GA41550>