802.11 QoS data frames

Question

I'm trying to parse 802.11 frames myself and I've encountered two problems that I can't solve.

First of all, when does an LLC (Logical Link Control) header follow a IEEE 802.11 data frame ? I thought when there is data in a frame, there would always be an llc overhead preceding the data, but I have a wireshark with Ethernet II instead of LLC. But I have no idea how to actually know if it's gonna be an LLC or a Ethernet II header following my 802.11 data header. There's no field in the 802.11 header specifyin what's following.

Secondly, I have noticed something in wireshark when I open a capture file containing 802.11 QoS data frames. At the end of the header there's the QoS control field, which is normal, it's specified in the IEEE 802.11 documentation (i've read it over and over again to try to find an answer to my question) But then, there's 2 bytes that wireshark considers part of the 802.11 header (when you click on the raw bytes, wireshark points to the 802.11 header, but the signification of the bytes is not displayed in the fields of the header ! Does my question make any sense ?

Here are images to explain what I'm not understanding. On the first screen shot below, you see the 802.11 header selected and you see below the concerned bytes in hexadecimal.

Pay attention to the last bytes of this packet:00 00 10 aa

Now I expand the 802.11 header and click on the very last field of it (QoS control, as specified in the RFC). You can see that the corresponding bytes are 00 00. But those bytes are not the last bytes of the packet ! There still is 10 aa that's part of the wifi packet but I have no idea what those bytes represent !

Any one has an idea ?

Answer 1

First of all, when does an LLC (Logical Link Control) header follow a IEEE 802.11 data frame ?

There should always be one, although things might be odd for aggregate packets. If you capture on an 802.11 interface and you're not capturing in monitor mode, you might see the packet begin with an Ethernet header, but that's different - that's the adapter and/or the driver translating the 802.11 header + LLC header into an Ethernet header.

But then, there's 2 bytes that wireshark considers part of the 802.11 header

That might actually be the "Atheros padding", "helpfully" inserted, in monitor mode, between the 802.11 header and the frame body by some Atheros network adapters. Open up the Radiotap header and see if the "Data Pad" flag is set in the Flags field; if so, the packet has "Atheros padding".