 | 1 | initial version |
IEEE 802a is now section 9.2.4 "OUI Extended EtherType" of IEEE 802-2014.
It's a way to provide the same capabilities as SNAP, but without using an IEEE 802.2 LLC header.
With SNAP, a protocol is identified by a 3-octet organizationally unique identifier (OUI),, combined with a 2-octet protocol identifier (PID). OUIs are handed out by the IEEE; an organization that has one (or more) OUIs can then assign its own protocol IDs to be used with one of those OUIs. "Organizationally unique" means that no given OUI should belong to more than one organization, so a given OUI/PID combination won't collide with a combination using the same PID but a different OUI.
With an OUI Extended EtherType, the EtherType value in the Ethernet header has the value 0x88B7, and it's immediately followed by a 3-octet OUI and 2-octet PID, followed by the payload for the protocol specified by that OUI/PID pair.
Just as a SNAP header with a non-zero OUI is used for various vendor-private protocols, so an OUI Extended EtherType with a non-zero OUI is used for the same purpose (and a given OUI/PID pair is used for the same protocol in SNAP and OUI Extended EtherType headers).
So, unless the OUI is all zeroes, it's "layer 2 raw traffic" in the sense that it's some protocol running directly on top of Ethernet, rather than on top of IP or TCP or UDP.
If the OUI is all zeroes, some software is being either silly or lazy; an OUI of 0 in a SNAP header or OUI Extended EtherType header means that the Protocol ID field is an EtherType.
For a SNAP header, that's used if there is no EtherType field in the packet, as is the case with most link-layer headers (Wi-Fi, for example), so an OUI of 0 serves a useful purpose - IPv6 packets over Wi-Fi, for example, have an 802.2 LLC header with source and destination Service Access Point values of 0xAA, indicating that after the 802.2 LLC header there's a SNAP header, and the SNAP header has an OUI of 000000 and a PID of 0x86DD, that being the EtherType for IPv6. (Yes, some Wi-Fi networks - mostly used in motor vehicle-to-motor vehicle communication - have an EtherType rather than an 802.2 header, but consumer Wi-FI doesn't.)
However, for an OUI Extended EtherType, there's no point in having an EtherType of 0x88B7, followed by an OUI of 000000, followed by a PID of 0x86DD, when you could just have an EtherType of 0x86DD.
So Wireshark currently doesn't handle that case.
Is the OUI in the OUI Extended EtherType header 000000? If so, it might be the traffic you're looking for, although it may be a bit unwise for whatever's sending it to send it in that fashion, as there's no guarantee that the host receiving it will understand it.
