3

I am using dpkt to parse some ieee80211 packets.
I see that the ieee80211 object created has wrong values.
Digging deeper I found that the ieee80211 treats the data as big endian while in practice the packets I am providing it are little endian.

Is there a way to detect the endianness of the packet in runtime so I could maybe change it to big endian before providing it to dpkt.ieee80211?

kroiz
  • 1,722
  • 1
  • 27
  • 43

3 Answers3

2

There shouldn't be anything to detect or guess. IEEE 802.11 is a standard protocol, and its specification states the correct endianess for each and every part of a frame. It the endianess is reversed, then the frame is malformed. You can grab the latest copy of the standard here.

Looking over the 3500+ page pdf (thank god for ctrl+f), it seems that most values are big-endian, just like in TCP/IP. But apparently, little-endian is used here and there. For instance, in some TKIP fields. Frankly, that's a bit surprising.

You haven't mentioned the frame/field you're trying to create/decode, so it's hard to say anything more specific than to look it up.

Malt
  • 28,965
  • 9
  • 65
  • 105
  • The field is the frame control. The first byte of the IEEE802.11 is 02 and the second byte is 08. Wireshark somehow knows to swap those two bytes and to figure that this is a Data frame (the 10 part of the 0000**10**00 which is the 08 which is the second byte but I expect to be the first). – kroiz Jul 25 '17 at 10:46
  • Does this help? https://stackoverflow.com/questions/12407145/interpreting-frame-control-bytes-in-802-11-wireshark-trace – Malt Jul 25 '17 at 12:03
  • In the Wireshark screenshot in that question you link to you can see that the wireshark says **(Normal)** on the "Frame Control" line. On my pcap Wireshark says **(Swapped)**. And the first byte on that question is 08 while in my pcap 08 is the second byte. So, I think some how Wireshark understood that in my IEEE80211 the first and second bytes need to be swapped. I just don't get how. – kroiz Jul 26 '17 at 05:47
  • I see. It's probably some buggy implementation that became common enough to become a de-facto part of the standard. These thing happen. We should look at the wireshark dissector code for these frames, see how they decide whether to flip these bytes. It it possible that 0208 is simply an invalid value, while 0802 is ok? – Malt Jul 26 '17 at 08:28
  • I read the relevant wireshark code but could not understand: There seems to be a call to register_dissector dissect_ieee80211_bsfc but I could not understand when it is used over the other dissectors. (bsfc stands for byte-swapped frame control) – kroiz Aug 04 '17 at 19:03
  • 1
    Unfortunately, I had the same problem. I see the registration, and the `IEEE80211_COMMON_OPT_BROKEN_FC` flag passed to dissection, but they don't seem to call `dissect_ieee80211_bsfc` neither by name (`wlan_bsfc`) nor by handle (since the handle isn't saved after registration). I suggest asking on https://ask.wireshark.org/ or their dev mailing list - https://www.wireshark.org/lists/ .Perhaps a Wireshark developer can help out. – Malt Aug 04 '17 at 20:20
1

The only way you're going to be able to detect endianness when you don't know one way or the other would be to inject a payload and have that parsed the same way.

You can then check for endianness by checking the identity of the payload you injected.

Haskell McRavin
  • 620
  • 5
  • 19
0

It turns out that for IEEE80211 under CAPWAP the frame control bytes are simply swapped.
It is probably an an-initial-mistake-gone-de-facto-standard case.
See answer in Wireshark Q&A

kroiz
  • 1,722
  • 1
  • 27
  • 43