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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ