Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Distinguishing Ethernet II and 802.3 frames

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Thu, 06 Mar 2008 02:02:39 -0800
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.