This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

CAPWAP 801.11 Data Header FCF Swapped - why?

1

I'm getting confused while trying to write code to read frames that contain a CAPWAP header. If I open the file in Wireshark, it prints "(Swapped)" next to the Frame Control Field of the IEEE 802.11 Data decode following the CAPWAP header, and I have no idea how Wireshark realized it needed to do that. I tried reading the packet-ieee80211.c source code file to find out what is being done, but I can't track it down...

This is how the decode of the CAPWAP frame looks like:

CAPWAP decode

If you look at the hex view you'll see that it says "01 08", which would normally decode to this being a management frame (Type = 0). But somehow Wireshark knows it needs to "swap" something (what exactly? Looks like the "01" byte lower nibble is swapped?). Very confused. Maybe someone with more 802.11 skill can shed a light? Thanks!

BTW don't get confused by the "2c" byte following the "01 08", that's the value for the 44 microsecond duration following the flags. It's not the 2c mentioned for the FCF. Not sure why that value is even mentioned at that position ("0x082c (Swapped)")...

asked 24 Sep '16, 16:38

Jasper's gravatar image

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

One Answer:

3

I'm not sure that an 802.11 skill alone (not that I'd have one) is sufficient here, it has to do with the dissector code and with how it is invoked.

If you take the 802.11 part of your frame alone (from your 01 08 till the end of the frame) and import them indicating a plain IEEE 802.11 Wireless LAN encapsulation, the wlan dissector doesn't handle them the same - in this case, it does interpret the contents of the FCF as announcing a retransmitted control frame, with all the impact to dissection of the rest of it. If you manually swap the two bytes of the FCF, making them 08 01, you get a much more logical interpretation as a TCP SYN packet on its way from STA to AP. Any "logical" operation (nibble or bit pair swapping) cannot explain a change from 0x1 to 0x8.

But the code, packet-ieee80211.c, contains the following remark:

/*
 * Dissect 802.11 with a variable-length link-layer header and a byte-swapped
 * control field and with no FCS (some hardware sends out LWAPP-encapsulated
 * 802.11 packets with the control field byte swapped).
 */
...
dissect_ieee80211_common(tvb, pinfo, tree, IEEE80211_COMMON_OPT_BROKEN_FC|IEEE80211_COMMON_OPT_NORMAL_QOS, &phdr);

(note the IEEE80211_COMMON_OPT_BROKEN_FC bit, and note that the comment probably means "with a byte-swapped control field", not "with a swapped control-field byte").

LWAPP (RFC 5412) is essentially an indirect reference to CAPWAP (RFC 5415), and CAPWAP doesn't say anything regarding changing the order of FCF bytes. However, there is no heuristic testing which interpretation of the FCF yields better results - encapsulation of the 802.11 frame into CAPWAP implies swapping of the FCF's bytes, dot.

So it seems to me to be an an-initial-mistake-gone-de-facto-standard case.

BTW, the occurrence of the 2c in the "swapped" interpretation of the Frame Control Field in the dissector is likely to be a bug, it really refers to the next byte and shows whatever is there.

answered 25 Sep '16, 04:18

sindy's gravatar image

sindy
6.0k●4●8●51
accept rate: 24%

edited 25 Sep '16, 05:41

Thanks, @sindy, this is pretty much in line with what I suspect (mistake-gone-de-facto-standard and "2c" being a bug) - the problem I have is how I can detect/determine that what I see is such a case and not a "normal" 802.11 header...

So you think the 802.11 dissector handles the decoding differently by knowing it was sent as a CAPWAP payload?

(25 Sep '16, 04:29) Jasper ♦♦
1

So you think the 802.11 dissector handles the decoding differently

I am sure that the fact that the data came CAPWAP-encapsulated alone causes the ieee80211 dissector to swap the FCF bytes while dissecting. I cannot show you the responsible line of the code but I have tested that by fiddling around with the packet data (changing the FCF byte order to the correct one in the complete frame and still getting them dissected as swapped).

how I can detect/determine that what I see is such a case

I'm not sure there is a reliable way to do it on a single frame. Over several (tens of) frames, trying to dissect them both ways and choosing the one which returns less errors might be sufficiently reliable.

(25 Sep '16, 04:51) sindy
1

Thanks, I think you're right... I'll try to check if the 802.11 layer was sent via CAPWAP and swap the FCF. I also converted your first comment to an answer so I can accept it ;-)

(25 Sep '16, 05:38) Jasper ♦♦

The issue seems to have been around since a while ago:

https://www.wireshark.org/lists/ethereal-dev/200309/msg00586.html (it is not the first encounter of the issue, just a note that the already existing preference has been moved to a more appropriate place)

http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob30dg/TechArch.html (still referring to LWAPP and Ethereal rather than CAPWAP and Wireshark)

http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mobility/emob73dg/emob73/ch2_Arch.pdf (an evolution of the same document which still doesn't explain why the CAPWAP encapsulation swaps the bytes).

(25 Sep '16, 06:17) sindy