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.