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

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

Message-ID: <CAGVrzcb8cOsfR0x7aiEmG1v1Bb067d-_amYQ4X4uqQp62q-q5Q@mail.gmail.com>
Date:	Wed, 14 May 2014 09:09:05 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	David Laight <David.Laight@...lab.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

2014-05-14 1:51 GMT-07:00 David Laight <David.Laight@...lab.com>:
> 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.

Yes that's what I am doing. I was confused because I enabled the
switch tagging, which inserts a 4bytes tag between the Ethernet SA and
the Ethertype field. That specific switch tag length is not taken into
account by the switch to determine if a packet is runt, because the
tag is extracted before the packet enters the parsing logic. The
minimum frame length really needs to be 64 bytes with the FCS, but
without the switch tag inserted, so if we want to be safe, regardless
of the switch tag being inserted or not, the minimum frame length
needs to be 68 bytes with the FCS.

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



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