> 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. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul_at_windriver.com | Wind River Systems ============================================================================= <adamw> you're just BEGGING to face the moose =============================================================================
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:05 UTC