Call for re(4) checksum offload testers.

[Pyun YongHyeon]

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