netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20120215163748.GA3998@elliptictech.com>
Date:	Wed, 15 Feb 2012 11:37:48 -0500
From:	Nick Bowler <nbowler@...iptictech.com>
To:	netdev@...r.kernel.org
Cc:	Realtek linux nic maintainers <nic_swsd@...ltek.com>,
	Francois Romieu <romieu@...zoreil.com>
Subject: Bogus frames transmitted with r8169 & fragmentation & large mtu

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,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

Download attachment "fragment-9000.cap.gz" of type "application/octet-stream" (527 bytes)