Ethernet II and Data following 802.11 Data frame?

Question

I was watching several wifi captures in wireshark and I bumped into two specimens I had never seen before. First of all, I thought that a IEEE 802.11 data frame would always be followed by a LLC header (802.2), provided that the frame actually contained data. Now I have a two wireshark captures showing otherwise !

First one, we can see an Ethernet II header following the wifi header :

Now that's the first thing I don't understand. How is an interface supposed to know, when reading the 802.11 Data header, that it is going to be an Ethernet II following ? There is no field in the 802.11 header specifying what's coming next.

Second is "raw data" directly following the wifi header.

Same question as before, how are we supposed to know that Data was following, and not LLC ?

Answer 1

First question:

To quote a comment in the Wireshark 802.11 dissector:

  /* I guess some bridges take Netware Ethernet_802_3 frames,
     which are 802.3 frames (with a length field rather than
     a type field, but with no 802.2 header in the payload),
     and just stick the payload into an 802.11 frame.  I've seen
     captures that show frames of that sort.

There is no field in the header that says "this is a bridged Netware Ethernet_802_3 frame", so Wireshark has to use a heuristic. The heuristic is "if the first two bytes of the payload are not both 0xAA, the first 6 bytes of the payload equal the destination MAC address, and the next 6 bytes of the payload equal the source MAC address, then this is a bridged Netware Ethernet_802_3 frame", in which case it calls the Ethernet dissector. Because this is a heuristic, it is, of course, not guaranteed to get the correct answer all the time.

IEEE Std 802.11-2012 says, in section 5.1.4 "MSDU format":

This standard is part of the IEEE 802 family of LAN standards, and as such all MSDUs are LLC PDUs as defined in ISO/IEC 8802-2: 1998. In order to achieve interoperability, implementers are recommended to apply the procedures described in ISO/IEC Technical Report 11802-5:1997(E) (previously known as IEEE Std 802.1H-1997 [B21]), along with a selective translation table (STT) that handles a few specific network protocols, with specific attention to the operations required when passing MSDUs to or from LANs or operating system components that use the Ethernet frame format. Note that such translations may be required in a STA.

"ISO/IEC 8802-2: 1998" is also ANSI/IEEE Std 802.2, 1998 Edition, so that says that the payload should begin with an 802.2 header. At least as I read IEEE Std 802.1H-1997, Ethernet frames without an 802.2 header should be translated to SNAP frames, using their Ethernet type value, when bridged to a LAN using 802.2, such as an 802.11 LAN. I guess, since Netware Ethernet_802_3 frames don't have a valid 802.2 LLC header and don't have a type field (they have a length field; I think that, as they don't have an 802.2 header following the Ethernet header, this means that they technically aren't valid Ethernet frames), they aren't covered by the specifications in question, so it's not technically a protocol error to just put the Ethernet packet, starting with the Ethernet header, into the data field. Presumably those packets are sent only to bridges, under the assumption that the bridge knows how to Do The Right Thing.

Second question:

The most common reason to see "Data" after an 802.11 header is that the packet in question is encrypted (WEP or WPA/WPA2) and Wireshark doesn't have the password for the network (and, for WPA/WPA2 Personal/Pre-shared key mode, doesn't have the initial EAPOL handshake in the capture; decrypting in Enterprise/802.1X mode is not supported).

Are you capturing on a "protected" (WEP or WPA/WPA2) network?