Have you used the packet capture facility of an Aruba Access Point to ship packets to Wireshark on your desktop? Have you wondered why Wireshark reports so many of the packets as “malformed?” Part of the problem is due to an Aruba bug and part of the problem is due to inconsistent processing by the Wireshark dissectors.
First, we must remember that the wireless medium is half-duplex. The AP where you are capturing packets cannot really “capture” the frames it is transmitting. The AP makes a copy of the frame at some point on the frame’s journey down the protocol stack so that the AP can ship the copy to your desktop. This necessarily means that what it ships to you will not be a true copy of what it sends out on the air because there are some values that get filled in after the point where the copy is made. And if you have specified a file format that includes radiotap information, much of that information will be missing because it didn’t really “capture” it over its radio.
Aruba’s bug occurs when the capturing AP makes a copy of a frame it is transmitting. It fails to append the four-byte “frame check sequence” (FCS). This shows up in Wireshark pretty clearly but it gets very confusing very quickly because it manifests itself differently based on the file format you chose when you set up the capture.
An Aruba packet capture supports six possible formats but only three of those formats are supported by Wireshark. The formats available to you also depend on whether you are doing an interactive or a raw capture and they depend on whether you are using the GUI or the CLI. The formats are identified by an ERM Type. ERM is Aruba’s “Encapsulated Remote Mirroring” protocol. This chart summarizes the feature set:
ERM Type | File Format | Raw | Interactive | Wireshark |
0 | pcap | CLI/GUI | CLI/GUI | Supported |
1 | peek | CLI/GUI | No | Supported |
2 | airmagnet | CLI | No | No |
3 | pcap + radio | CLI | No | Supported |
4 | ppi | CLI | No | No |
5 | peek + n/ac | CLI | No | No |
Capture Filters | --------------> | No | CLI/GUI | |
On the Wireshark side we must also be aware of how the ERM dissectors work. The ERM Type 1 dissector assumes the last four bytes of the frame are to be used as the FCS. The ERM Type 0 and Type 3 dissectors assume the FCS is not included in the frame. Unfortunately, the “Assume packets have FCS” checkbox at “Edit | Preferences | Protocols | IEEE 802.11” has no impact. It is unclear why these dissectors work differently since there is no difference in the way Aruba handles the FCS.
Let’s talk about ERM Type 1 first because the problem is easy to see in Wireshark. Because Wireshark uses the last four bytes of the frame as the FCS, and because Aruba includes the FCS on the frames received by the AP but not on the frames transmitted by the AP, Wireshark sees the frames that were transmitted by the capturing AP as “malformed.” This shows up very clearly in the Management frames transmitted by the capturing AP. Wireshark uses the last four bytes of the frame as the FCS and then can’t decode the final field correctly.
The situation is pretty much reversed for ERM Type 0 and Type 3. Because Wireshark does not think the frame has an FCS, it tries to decode the last four bytes of frames received by the AP as part of the frame. For received Control frames, those last four bytes are ignored by Wireshark, probably because a Control frame is a fixed length (though it seems to me that Wirehsark should report the frame as malformed). For received Data frames, Wireshark just assumes those last four bytes are part of the data payload. Where we see the problem is in received Management frames. Wireshark tries to decode those last four bytes as a “Tagged parameter” and fails.
Of course some of those packets may legitimately be malformed but most occurrences can be safely ignored. I would like to thank Kevin Schoenfeld for his fine analysis of this issue and his help in identifying the problems. For additional details, his 5-part blog on this issue starts here: http://kjspgd.net/?p=30.