Interpreting Frame Control bytes in 802.11 Wireshark trace

Question

I have a Wi-Fi capture (.pcap) that I'm analysing and have run across what appear to me to be inconsistencies between the 802.11 spec and Wireshark's interpretation of the data. Specifically what I'm trying to pull apart is the 2-byte 802.11 Frame Control field.

Taken from http://www4.ncsu.edu/~aliu3/802.bmp, the format of the Frame Control field's subfields are as follows:

And below is a Wireshark screen cap of the packet that has me confused:

So as per the Wireshark screenshot, the flags portion (last 8 bits) of the Frame Control field is 0x22, which is fine. How the Version/Type/Subtype being 0x08 matches up with Wireshark's description of the frame is what has me confused.

0x08 = 0000 1000b, which I thought would translate to Version = 00, Type = 00 (which I thought meant management not data frame) and Subtype = 1000 (which I thought would be a beacon frame). So I would expect this frame to be a management frame and more specifically, a beacon frame. Wireshark however reports it as a Data frame. The second thing that is confusing me is where Wireshark is even pulling 0x20 from in the line Type/Subtype: Data (0x20).

Can anyone clarify my interpretation of the 802.11 spec/Wireshark capture for me and why the two aren't consistent?

Answer 1

The data frame in you example is 0x08 because of the layout of that byte of the frame control (FC). 0x08 = 00001000 - The first 4 bits (0000) are the subtype. 0000 is the subtype of this frame - The next 2 bits (10) is the type, which is 2 decimal and thus a data type frame - The last 2 bits (00) are the version, which is 0

The table below translates the hex value of the subtype-type-version byte of the FC for several frame types. A compare of the QoS data to the normal data frame might really help get this down pat. Mind you the table might have an error or two, as I just whipped it up.

You are right that 1000 is a beacon frame, you just were looking at the wrong bits.

You have a radiotap header, you can get the dec representation of the type like so from the pcap API:

int type = pkt_data[20] >> 2;

Answer 2

This is a common error, and has certainly bitten me several times.

It is down to the Byte Ordering.

When you have a multi-byte number to represent, the question arises as to Which byte do you put/send first ?

Natural (human) byte order is to put the big part first, then the smaller parts after it, Left-to-right, also called Big Endian. Note that the Bits in each byte are never the wrong way around from a programmers' point of view.

e.g. 1234 decimal requires 2 bytes, 04D2 hex. Do you write/send 04 D2, or D2 04 ? The first is Big-endian, the second is Little-endian.

To confuse it more, the mechanisms involved may use different byte-orders.

There is the Network Byte Order, in this case Little-endian, the Architecture byte order (can be different for each CPU architecture) and the data may be in a buffer, so it will vary depending on whether you read the buffer top-to-bottom, or bottom-to-top.

It doesn't help that the explanation of which bits do what can also be 'backwards', as in your original post.

Answer 3

I am using wireshark version-2.4.3 on windows. My capture file of dataframes is like below.

Frame control field = 0x0842 i.e., in binary format 0000 1000 0100 0010 
Framecontrol flag field = 0x42.i.e., in binary format 0100 0010

So, as per my understanding the LSB 8bits in a framecontrol field will correspond to flags.

MSB 8bits will correspond to subtype, type, version i.e. in my case 0000-subtype & 10-type & 00-version.

Which is data frame of subtype 0.

It might be the error with wireshark in your case. It should dispaly frame control field as 0x0822 instead of 0x2208.

Flags field is properly displayed as 0x22.

In My case I am using wireshark-2.4.3 and display of frame control field is correct 0x0842 where flags is 0x42.

My_capture_file: