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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1329333239.2469.3.camel@edumazet-laptop>
Date:	Wed, 15 Feb 2012 20:13:59 +0100
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Nick Bowler <nbowler@...iptictech.com>
Cc:	netdev@...r.kernel.org,
	Realtek linux nic maintainers <nic_swsd@...ltek.com>,
	Francois Romieu <romieu@...zoreil.com>
Subject: Re: Bogus frames transmitted with r8169 & fragmentation & large mtu

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 ?



--
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