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: <7c923b5e0709210727s527e79c7w790102128ed0dd6@mail.gmail.com>
Date:	Fri, 21 Sep 2007 16:27:54 +0200
From:	"Francesco Fondelli" <francesco.fondelli@...il.com>
To:	hadi@...erus.ca
Cc:	"Emil Micek" <emil.micek@...jasek.cz>,
	"auke-jan.h.kok@...el.com" <auke-jan.h.kok@...el.com>,
	"netdev mailing list" <netdev@...r.kernel.org>,
	"Ben Greear" <greearb@...delatech.com>
Subject: Re: change the way e1000 is handling short VLAN frames

On 9/21/07, jamal <hadi@...erus.ca> wrote:
> Hope that makes sense.
[cut]
> cheers,
> jamal

Hi all,

as far as I understand ieee docs both 64 and 68
approaches are fine...

--- Std 802.1Q-2005, 6.5.1 ---
On receipt of an M_UNITDATA.request primitive that
represents a tagged frame, the implementation is
permitted to adopt either of the following approaches
with regard to the operation of Transmit Data
Encapsulation for frames whose length would, using the
procedure as described, be less than 68 octets:
a) Use the procedure as described in 6.5.1 of IEEE
Std 802.1D. This procedure can result in
tagged frames of less than 68 octets (but at least 64 octets)
being transmitted; or
b) Include additional octets before the FCS field in order
for the transmitted frame length for such frames to be
68 octets. This procedure results in a minimum tagged
frame length of 68 octets.
When a tagged frame of less than 68 octets in length
is received on a CSMA/CD LAN segment, and is forwarded
as an untagged frame, the provisions of 6.5.1 of
IEEE Std 802.1D, result in additional octets
being included before the FCS field on transmission
in order that the transmitted frame length meets the
minimum frame size requirements of 3.2.7 in IEEE Std 802.3.
------------------------------

and

--- Std 802.1Q-2005, C.4.4.1 ---
When tagged frames are transmitted by a Bridge on an
IEEE Std 802.3 MAC, there are two permissible
approaches (7.2), as follows:
a) Keep the minimum frame size generated by the Bridge
equal to 64 octets. This implies that the
number of pad octets in a received untagged IEEE Std 802.3
frame would be reduced by up to 4 octets when that frame
was tagged;
b) Adopt a minimum tagged frame length of 68 octets.
This implies that the number of pad octets in a
received untagged IEEE Std 802.3 frame would not be adjusted
when tagging such frames; equally, if subsequently untagged,
no pad adjustment would be necessary before transmission on
IEEE 802.3/Ethernet.
------------------------------

might this problem be solved using a configurable parameter?
(default=68)

my 0.02 euro
Ciao
FF
-
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