Packet Capture with AP Radios – What’s Under the Hood?

Posted by Hemant Chaskar on May 18, 2014 10:55:32 PM

Wireless packet capture has always been important to Wi-Fi professionals and support engineers for resolving network problems. With the diversity of wireless clients that is already around and which is only expected to grow with the Internet of Things (IoT), packet capture capabilities will continue to be critical. Wireless packet capture can be facilitated in the AP radios using the hardware and the driver level hooks. Read on to find out what’s under the hood.

There are two main plumbing points to get frames from wireless up to the application: one in the hardware and the other in the driver software. At the hardware level, the radio supports “Promiscuous Mode” option. When this option is activated, the hardware passes all wireless frames received on the channel where the radio is operating up towards the driver software. When this option is deactivated, the hardware passes only the wireless frames for the MAC of the radio (and the frames like probe requests & beacons based on the additional sub-settings under non-Promiscuous mode) up towards the driver software.

The driver software can operate in AP, STA, or Monitor Mode.

In the AP mode, the driver performs AP-related functions such as beacon generation, association management etc. and deactivates the Promiscuous Mode in hardware. When in the STA mode, the driver performs client-related functions such as probing, AP selection, connection management etc. and deactivates the Promiscuous Mode in the hardware. In the Monitor Mode, none of the AP or client-related function is performed by the driver, but now the hardware is set in the Promiscuous Mode to receive all frames on the channel and pass them to the driver software.

Figure 1: Default Hardware and Driver Modes Figure 1: Default Hardware and Driver Modes (click to enlarge)

T-OFF Frame Capture without Interrupting AP Service

With the driver in AP mode (and the hardware in non-Promiscuous Mode), it is possible to perform some useful wireless packet capture for the BSSID to troubleshoot connectivity issues between some client and the AP. Software code to T-off the packet stream between the hardware and the driver does the trick. In this T-off process, the frames received by the AP are tapped when they move up from the hardware to the driver, while the frames generated by the AP are tapped when they move down from the driver to the hardware. The AP’s operation does not stop during the packet capture, so the Wi-Fi service is not disrupted.

Adding Cross Traffic and More Frames to T-OFF

It is possible to change the default AP mode behavior by setting the Promiscuous Mode in the hardware while the driver is operating in the AP Mode. Now this radio will receive not only the frames for the AP BSSID but also other frames on the channel where radio operates and pass them to the driver. Also, control packets received by the AP are now also passed to the driver (which in the non-Promiscuous mode are terminated at the hardware itself unless explicitly passed through via the hardware filter setting under the non-Promiscuous mode). In the Promiscuous mode, failed received frames due to CRC error at the AP are also passed up to the driver. We can then T-off these frames as above without stopping the AP operation.

Figure 2: T-off Frame Capture Figure 2: T-off Frame Capture (click to enlarge)


When Would You Need a Second Radio for Capture?

Certain frames may still not be available in the T-off process in the AP mode. Though exact categories may be hardware and driver dependent, two good examples are: control packets generated by the AP and retransmissions from the AP. In the AP mode, control frames and retransmissions going from the AP to the client may be generated by the hardware and not the driver. As a result, in the T-off process, they may not be available in the captured stream. Also, in the T-off process, there could be some differences between the relative sequence in which the frames appear on the wireless link and the relative sequence of frames in the captured stream (for the frames going from AP to client as they are captured before transmission).

If such factors are essential for troubleshooting, the way out is to use the Promiscuous Mode on the second AP to capture frames on the wireless side for the first AP, which will now include the control packets and retransmissions generated by the first AP. The flip side is that it may require stopping operation of the second AP, since it may be tuned to a different channel than the first AP. This then effectively boils down to using the Monitor Mode for the second AP’s radio.

Another alternative is to use the second radio on the same AP in Monitor Mode to capture frames for the first radio. This is possible on the APs with the band unlocked radios, where the second radio can tune to any 2.4 GHz or 5 GHz channel while the first radio is operating as AP.

What Does This All Mean in Practice?

In the distributed network scenarios, onsite engineer is usually not available to perform wireless packet capture using client based tools. Then, using APs for packet capture becomes handy. You can perform packet capture on the operational AP without stopping its service in the non-Promiscuous mode with the T-off between the driver and the hardware. Or, on the AP without stopping its service in the Promiscuous mode to add more types of frames to the T-off stream. The hardware mode change from the non-Promiscuous to the Promiscuous can be done on the fly without stopping the radio.

In some cases, the second radio in Monitor Mode (on a different AP or on the same AP such as AirTight C-60 that supports band unlocked radios) may be required to perform packet capture to include additional frames and additional details in the captured stream.

Obtaining remote packet capture is the first and important step in troubleshooting distributed wireless networks. The second step is then to upload the captured packet trace to the cloud and use analysis tools to spot the problem.

Additional reference:

Enjoyed this post? Don't miss future ones. Subscribe by email.

Topics: WLAN Troubleshooting

Subscribe to Email Updates