netdev - Re: change the way e1000 is handling short VLAN frames

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <46F435CD.1090502@intel.com>
Date:	Fri, 21 Sep 2007 14:21:17 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	hadi@...erus.ca
CC:	Ben Greear <greearb@...delatech.com>,
	Emil Micek <emil.micek@...jasek.cz>,
	netdev mailing list <netdev@...r.kernel.org>,
	Jesse <jesse.brandeburg@...el.com>
Subject: Re: change the way e1000 is handling short VLAN frames

jamal wrote:
> On Fri, 2007-21-09 at 08:43 -0700, Ben Greear wrote:
> 
>> I just re-read the spec, and a bridge *may* pad up to 68, but it is not 
>> required.
>> On page 166, it says equipment must be able to handle 64 byte minimums.
>>
>> See page 22 (section 7.2) of this document:
>>
>> http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf
>>
>> Also, page 63, 165, 166
> 
> Thanks for the enlightnment. 
> Do we need an ethtool interface to turn off hardware accelerated vlans?
> Jesse is indicating that the intel hardware can only handle the MUST but
> not the SHOULD of the spec.

I don't actually see the "SHOULD" part you are referring to. AFAIK the RX side is
fully covered and only on TX the hardware sends out 64b padded vlan packets, which
is permitted. The spec never says that it is required to send out 68b padded vlan
packets - only permits either choice.

Auke

-
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