| 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
| ||
|
Date: Thu, 16 Feb 2012 11:14:42 -0500 From: Nick Bowler <nbowler@...iptictech.com> To: Eric Dumazet <eric.dumazet@...il.com> Cc: Francois Romieu <romieu@...zoreil.com>, netdev@...r.kernel.org, Realtek linux nic maintainers <nic_swsd@...ltek.com> Subject: Re: Bogus frames transmitted with r8169 & fragmentation & large mtu On 2012-02-16 05:19 +0100, Eric Dumazet wrote: > 1) Are you using SLUB, SLAB, or SLOB ? SLUB. > 2) Problem with MTU=9000 is that frames span several 4K pages. > > Maybe some versions of r8169 hardware have problems with that ... Could be, but probably not the whole story. I tested some >4k MTU values (all with 60K packets here because it failed more reliably than 30K). 6500 byte MTU appears to work OK (<1% loss). 7500 fails (>99% loss). A largish range of MTU settings inbetween achieve a roughly 50% loss rate. The corruption is not always as significant as the original trace: some of my tests had all the fragments correct but a mere two bytes of payload were zero (resulting in the reassembled datagram being dropped due to a checksum failure). Recall that the original trace also had this "two bytes zeroed" problem in the second fragment, in addition to all its other problems. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) -- 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
Powered by blists - more mailing lists