Wireshark-users: Re: [Wireshark-users] Distinguishing Ethernet II and 802.3 frames
Marcus Better wrote:
I'm looking at some traffic in our LAN, and think I have some problems with
Ethernet II vs 802.3 framing.
Wireshark shows lots of Ethernet II frames with "unknown" frame type 0x05ec
(=1516 decimal). Since that is less than 0x0600, the limit for Ethernet
frames, shouldn't Wireshark interpret this as an 802.3 frame rather than
Ethernet II?
Well, to quote 802.3-2005 section 3.2.6 "Length/Type field":
This two-octet field takes one of two meanings, depending on its
numeric value. For numerical evaluation, the first octet is the most
significant octet of this field.
a) If the value of this field is less than or equal to the value of
maxValidFrame (as specified in 4.2.7.1), then the Length/Type field
indicates the number of MAC client data octets contained in the
subsequent data field of the frame (Length interpretation).
b) If the value of this field is greater than or equal to 1536
decimal (equal to 0600 hexadecimal), then the Length/Type field
indicates the nature of the MAC client protocol (Type interpretation).
The Length and Type interpretations of this field are mutually
exclusive.
maxValidFrame is 1500, so if the length/type field has a value in the
range 1501 through 1535, 802.3-2005 doesn't specify how to interpret the
frame. 1516 is in that range, so Wireshark can interpret the packet as
an 802.3 frame, an Ethernet II frame, or a plaintive love note from the
ghost of Richard Milhous Nixon to Margaret Thatcher, and none of those
interpretations would violate IEEE 802.3.
In fact the frames have a payload of precisely 1516 bytes, so it seems that
it is indeed a regular 802.3 frame.
(Well, technically speaking, Ethernet II frames *are* 802.3 frames, at
least as of 802.3x, but....)
Incidentally the strange frames are all sent from a Netgear wireless router
to some MacOS X laptops, over a WEP-protected 802.11 network.
Argument number 1,273 against 802.11 adapters and/or drivers removing
the 802.11 header from frames, slapping a fake Ethernet header on the
frames, and presenting them to the host and/or host networking stack -
packets of certain sizes cannot be so transformed in such a way as to
allow them to be correctly interpreted according to 802.3.
Unfortunately, OS X doesn't follow in the footsteps of
{Free,Net,Open,DragonFly}BSD by allowing an application using BPF to
select either Ethernet or 802.11 headers, regardless of whether you're
capturing in monitor mode or not, so you can't just say "please give me
802.11 headers", thus bypassing the 802.3/Ethernet II dissector, and
therefore bypassing the "is it a length field or is it a type field?"
check. (It somewhat follows in the footsteps of Linux and Windows Vista
in that regard, alas, i.e. they support 802.11 headers only in monitor
mode, as far as I know.)
I suppose interpreting packet length/type values in that particular dead
zone as having a length field would help in this case; I don't know
whether it would cause problems with any packet types you'd see on, for
example, a regular Ethernet.
