netdev - RE: [PATCH net-next v4 2/2] net: systemport: pad packets to a minimum of 64 bytes

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: <063D6719AE5E284EB5DD2968C1650D6D172442ED@AcuExch.aculab.com>
Date:	Wed, 14 May 2014 08:51:07 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Florian Fainelli' <f.fainelli@...il.com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [PATCH net-next v4 2/2] net: systemport: pad packets to a
 minimum of 64 bytes

From: Florian Fainelli 
...
> >>> +     if (skb_padto(skb, 64)) {
> >>
> >> Shouldn't that be 60?
> >
> > It should, absolutely, and that is ETH_ZLEN. Thanks!
> 
> In fact, no, despite the Ethernet MAC appending the CRC, the minimum
> packet length from the DMA perspective really needs to be 64, as the
> hardware inserted CRC is not accounted for to generate the End of
> Packet signal. That just translates into ETH_ZLEN + ETH_FCS_LEN
> anyway.

Hmmm.... That really doesn't sound right.
The CRC can't be replacing the last 4 bytes of the skb - otherwise
longer packets would be corrupted.
So I'm sure that you are padding frames to 68 bytes.
While a typical IP implementation probably ignores pad bytes after
any length frame, other protocols will only expect padding on short
frames - and then only to the minimum frame length.

	David