This blog details an analysis of the packet capture capabilities of the WLAN Pi and seek to answer the question:- “can it be used to capture four 20MHz channels simultaneously?”. But before we delve into the detail, let’s start with some background and acknowledgments. The WLAN Pi is a WLAN testing tool built upon the NanoPi Neo2 single-board-computer (SBC) and has been developed by Jerry Olla – for more information please visit www.wlanpi.com. With the recommended Comfast CF-912AC Adapter, a user of the WLAN Pi can perform wireless packet capture.
Nigel Bowden developed a bat file called WLANPiShark which configures the WLAN Pi to be used as a TCP dump adapter to stream frames directly in to WireShark (See Nigel’s blog here).
Following Nigel’s blog, Gjermund Raaen wrote a blog article (here) describing how he was able to capture four 20MHz channels by using the WLAN Pi and WLANPiShark configured for one 80MHz wide capture channel. An obvious initial reaction to Gjermund’s blog was to point out that it is not possible to simultaneously capture on four 20MHz channels from one adapter. Gjermund was kind enough to share his capture files and very quickly it could be confirmed that he had in fact captured packets on all four 20MHz channels, within a single 80MHz channel, with very little packet loss.
A lab was therefore set up to try and understand the capabilities of the WLAN Pi packet capture solution and how the NIC’s 80MHz monitor mode was actually working.
How an 802.11 NIC configured for 80MHz channels receives data
Before we go any further, it is important to understand how an 802.11ac NIC receives packets. 802.11ac 80MHz channels are composed of two 40MHz channels, bonded together. Each 40MHz channel is the product of two 20MHz channels bonded together. When APs are configured to operate on 80MHz channels, primary 40MHz and 20MHz channels are selected. When an 80MHz AP needs to talk to STA’s (stations) using 20MHz or 40MHz transmissions, it will usually transmit these on its primary channels. Figure 1 below illustrates an example of an 80MHz channel and its primary 20MHz and 40MHz channels.
Figure 1: Example 80MHz channel
When an 802.11 STA is operating on an 80MHz channel, it will listen on its primary 20MHz channel for PHY (physical) layer preambles and headers. 5GHz PHY preamble and headers are always transmitted on a 20MHz channel at 6Mbps using BPSK modulation. Information within the PHY header informs the STA how to receive the pending MAC frame – which includes the channel width, MCS, number of spatial streams and whether or not to use a short guard interval. Following the PHY header, the receiver will switch channel width, modulation, etc in order to receive the MAC frame.
After receiving the MAC frame, an STA will look at the receiver and BSSID MAC address to determine if it needs to pass this frame up the protocol stack.
How protocol analysers receive frames
As many will know, a popular protocol analyser is LiveAction’s Omnipeek. When fitted with the OmniWiFi adapter in monitor mode, Omnipeek receives frames in the same manner that a standard 802.11 STA does … with one exception. Although it listens on the configured primary 20MHz channel for PHY headers to know how to receive an imminent MAC frame, in monitor mode the adapter will pass all MAC frames up the stack to the analyser regardless of the frame’s MAC addresses. Therefore, if we configure our analyser to capture 802.11ac primary CH36, as indicated in Figure 1, our capture would receive all frames transmitted on the configured 80MHz, primary 40MHz and primary 20MHz channels. However, it would not receive frames transmitted on the secondary 20MHz or 40MHz channels because their PHY headers would not be transmitted on CH36.
Why is the WLAN Pi packet capture different?
To investigate how the WLAN Pi was performing an 80MHz packet capture, the lab environment shown in Figure 2 was setup and the WLAN Pi was configured as a TCP dump adapter into Omnipeek The WLAN Pi’s Comfast CF-912AC Adapter was set to CH52 80MHz.
Figure 2: Lab network
Test 1 – Ping
For the first test, a continuous Ping to WLAN controller was sent from each laptop. Initial analysis of the beacon frames captured showed that beacons were being captured from each of the lab APs. In Figure 3 you can see the beacon frames. Notice the capture channel is set to Channel 52 for all frames, but the channel on which the Beacons were transmitted is shown in the “Decode: Primary Channel” column.
Figure 3: Beacon Frames in Ping test
If we look at the WLAN statistics, we can see that we have captured frames from all four APs and their associated laptops.
Figure 4: Packet and Byte statistics from Ping test
However, taking a closer look at these statistics, we notice that far more packets have been captured on channel 56 than for the other channels. Further investigations revealed that, although we captured most of the packets transmitted by Laptop 2, most of the packets captured from Laptops 1, 3 and 4 were mainly control, management and broadcast data frames with the majority of the unicast data frames absent.
Why was the WLAN Pi adapter favouring channel 56? The primary capture channel was changed to channel 64; but the WLAN Pi adapter still favoured data from channel 56. Power cycling the WLAN Pi had no effect on this behaviour.
Test 2 – Throughput.
For the second test a large download was initiated on each laptop. This time the capture was configured on channel 64 with an 80MHz channel width. The results were similar to those from the ping test but this time channel 52 was the favoured channel and the difference between the volume of packets captured for each channel was much clearer.
Figure 5: Packet and Byte statistics from Throughput test
From this test, it was clear that while the WLAN Pi’s adapter was tied up capturing a frame on one 20MHz channel it was not able to simultaneously capture frames on the other 20MHz channels across the same 80MHz channel.
Conclusions
When configuring the WLAN Pi with a Comfast CF-912AC adapter in Monitor mode with an 80MHz channel width, the following conclusions were drawn:
- The adapter will listen for PHY preamble and headers on all individual 20MHz channels within an 80MHz channel. Whether or not it does this simultaneously or cycles though these is unclear from this testing.
- The adapter is not able to capture frame transmissions on two 20MHz channels simultaneously. While it is receiving a frame on one 20MHz channel it will ignore the other 20MHz channels within the same 80MHz channel.
- The adapter will favour one of the 20MHz channels during capture. A way was not found for predicting which channel will be favoured. Therefore, this 80MHz capture solution is unusable for detailed analysis and troubleshooting work, as there is no way to guarantee you will capture on the channel you require. The recommendation is to only select 20MHz channel captures with the WLAN Pi if you want to guarantee a valid 20MHz captures.
While the WLAN Pi is not going to replace the packet capture tool kit yet, the 80MHz monitor mode of the CF-912 is interesting. Perhaps if there could be more control over its behaviour, there may turn out to be some valid use cases.
