Revision history [back]

At layer 2, an Ethernet frame has, starting at the beginning:

• a 6-octet destination address;
• a 6-octet source address;
• a 2-octet big-endian type/length field.

If the type/length field has a value <= 1500, it's a length field, giving the length of the payload following the Ethernet header (note that Ethernet packets must be padded to a length of 60 octets, not counting the FCS, so you can't use the on-the-wire length of the Ethernet packet to determine how much payload there is). The payload of such a packet either has an IEEE 802.2 header, or two bytes of 0xFF, at the beginning. The two bytes of 0xFF mean that the payload is a Netware IPX frame, using a very old legacy encapsulation.

The 802.2 header has a Destination Service Access Point (DSAP) as the first octet and a Source Service Access Point as the second octet; if the DSAP is not 0xAA, it's used to indicate the protocol for the payload following the 802.2 header; if it's 0xAA, the 802.2 header is followed by a SNAP header, which had 3 octets of IEEE Organizational Unit Identifier (OUI) and 2 octets of protocol ID (PID). The OUI specifies a "namespace" for the PID, so an OUI/PID combination indicates the protocol for the payload; an OUI of 0x000000 means that the PID is an Ethernet type, giving the protocol for the payload following the SNAP header.

If the type/length field has a value >= 1536, it's a type field containing an Ethernet type, giving the protocol for the payload following the Ethernet header.

(If the type length is between 1501 and 1535, the frame is invalid.)

Wireshark handles that when it dissects packets. If the type/length field is a length field, it's represented in the dissection as an "eth.len" field; if it's a type field, it's represented as an "eth.type" field.

For frames with a length field, the 802.2 DSAP is represented in the dissection as an "llc.dsap" field. If there's a SNAP header, the OUI is represented as an "llc.oui" field and the PID is represented as an "llc.pid" field.