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 interpretati

Answer 1

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 2

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 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: