Re: Bogus frames transmitted with r8169 & fragmentation & large mtu

[Eric Dumazet <eric.dumazet@gmail.com>]

Le mercredi 15 février 2012 à 11:37 -0500, Nick Bowler a écrit :
> Hi folks,
> 
> We were testing IPsec with large mtu sizes (9000 bytes) and noticed the
> occasional failure with large datagrams (requiring several fragments,
> >=25k bytes or so).  Investigating further, I was able to reproduce the
> issue without using IPsec at all.  Looking at the wireshark capture I
> see that one of the fragments transmitted is totally bogus: portions of
> the payload data have made it onto the wire as the headers.  My test
> case was this:
> 
>   ping -c 1 -s 30000 -p 42 birch
> 
> which is split into 4 frames, 3 of which (first, second and last) look
> correct but the fourth consists entirely of 0x42 octets, including the
> ethernet and IP headers (so the source address is 42:42:42:42:42:42, the
> destination address is 42:42:42:42:42:42, ethertype is 0x4242, etc.)
> I've attached the wireshark capture (gzipped) since it's small enough.
> Nevertheless, the total length is correct for the missing fragment.
> 
> It seems to be specific to the particular network chipset on this
> machine (using the r8169 driver):
> 
>   Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
> 
> because the other machine (which has a Marvell controller) transmits
> fine as far as I can tell.  I'll see about putting a discrete network
> card in this computer to see if that helps any.
> 
> It's not entirely consistent in how things fail.  Sufficiently small
> pings (say, <=20k bytes) seem to work 100% of the time, sufficiently
> large pings (say, >= 40k bytes) seem to fail 100% of the time, and in
> between most pings fail but the occasional one makes it through.
> Everything works at all sizes with 1500 byte MTU.
> 
> There are no unusual messages in dmesg and this was all run with latest
> Linus' git as of this morning.  It occurred with somewhat older kernels
> (2.6.39) as well, even though the driver only let me go to 7200 byte mtu
> on that version.
> 
> Let me know if you need any more info,

Interesting, but 2nd frame is also corrupted (not at the start but in
the middle)

Where was taken this trace exactly ?