Frame capturing of 802.11frames, WiFi, is a important task in managing and troubleshooting WiFi networks. In the earlier days there were different methods of capturing these frames, but now when 802.11ax (WiFi6) is in the marked the variety in methods is limited.

Capturing the management and control types of frames that normally use legacy frame formats like 802.11b/g in the 2.4GHz band and 802.11a in the 5GHz is still easily done, but capturing the data frames with 802.11ax frame format is more tricky.

I will in this blog compare 802.11ax frame capturing using a Jetson Nano with Intel ax200 wireless NIC and a Cisco C9115-AXI in sniffer mode

Disclaimer: This is not an attack in either Wireshark or Cisco. It is just a comparison between those two methods

Capturing with NVIDIA Jetson Nano
I have several blogs describing 802.11 frame capturing, and especially 802.11ax OFDMA frames, with the Jetson Nano. This one is the latest. The Jetson Nano can be used as a remote capturing device both on MacBook using Airtool 2.0 and on Windows using the SSH Remote Capture feature in Wireshark. I am mostly using Wireshark on a Windows client and as long you have an SSH connection to the Jetson Nano you can manage it from an SSH terminal and it can send captures to the Windows client

Cisco APs in Sniffer Mode
Cisco APs can be put in sniffer mode and it will then send the captured data to a predefined IP-address, in my case my Windows client. This data is encapsulated in a tunnel and when it enters Wireshark the first thing to do is select one of the UDP frames, right-click, and decode it as PEEKREMOTE. If you need help with it, do a search on the internet. Several WiFi professionals have blog articles on the topic

Testscenario
In my test lab network I use a Cisco C9115-AXI as the AP and the 9800CL controller on an Intel NUC. I am using Cisco 9800CL version 17.3.3. The configured SSID is an open/unencrypted WLAN so I can have visibility into the data traffic.
Another Cisco C9115-AXI is first configured with the same image and then converted to a sniffer AP. When the AP boot up again, I configure the 5GHz radio to the test channel and the ip address for my Wireshark client.
The Jetson Nano is managed through my Putty terminal to capture on the same channel.

To start testing, I run two instances of Wireshark on my Windows client. One with SSH Remote Capture towards the Jetson Nano and the other capturing on my ethernet NIC where the captured data from the AP arrives.
Then associate an 802.11ax client to the SSID and do a ping to 8.8.8.8, or something else.

Selecting a frame
From my two captures, I find the same frame. In this case, it is the first ping reply. Those two frames are merged together in one file and are attached to this blog
The first frame in the capture is the one from the Jetson Nano and frame number two is the same frame captured on the AP

Comparing the Packet Details subtrees
Wireshark, in newer versions, organizess the capture in four parts: Packet List, Packet Details, Packet Bytes, and Packet Diagram. The Packet Details subtree for the two different capturing methods looks like this:

The big difference between those on a high-level view is that the capture from the AP is encapsulated in a UDP tunnel. When interpreting the lowest levels of the subtrees; IEE 802.11 QoS Data, Logical-Link Control, Internet Protocol Version 4, and the ICMP, there is no difference between the data captured with these methods.

But when we start looking into the 802.11 radio information subtree and the radiotap header, which are called Airopeek/Omnipeek encapsulated IEEE 802.11 in the capture from the AP, we will see a big difference between the captures.

The information in those two headers is additional information the wireless NIC (or its driver) adds to the frame when it is been captured. And this additional information has a key-value when managing and troubleshooting wireless networks. Different wireless NICs adds different information to the captured frame.

Radiotap Header and 802.11 radio information from the Jetson Nano
This is the Radiotap Header and 802.11 radio information from the ping replay frame captured on the Jetson Nano:

I have highlighted the most important information:

– HE information: This is an 802.11ax frame
– PPDU format: HE_SU; single-user PPDU format
– Coding: LDPC which are mandatory for the most complex modulation types in 802.11ax
– Data Bandwidth/RU allocation: 20; this a frame on a 20MHz channel
– GI: 1,6 microsecond: the frame is using this guard interval
– NSTS: 2 spatial streams
– Antenna signal: -47dBm. The received RSSI for the frame on the capturing device on one of the antennas. The other has -46dBm
– Data rate: 195,0 Mb/s. The combination from previous information results in this data rate
– Channel: 140. The frame is captured on channel 140

This capture contains mostly all information I want to look for in the additional information of a frame capture

Airopeek/Omnipeek encapsulated IEEE 802.11 and 802.11 Radio Information from the capturing AP
The Airopeek/Omnipeek encapsulated IEEE 802.11 and 802.11 Radio Information from the capturing AP looks like this:

I have highlighted the most important information:
– Modulation type: 256-QAM
– Coding rate : 3/4. Those two values give the mcs-index of mcs8
– PHY type: 802.11ax (HE). It is an 802.11ax frame
– Channel 140: The frame is captured on channel 140
– Signal level: -41dBm. The RSSI of the captured frame on the capturing AP

What am I missing from the capture on the AP?
There is a lot of information missing on the capture from the AP compared to the capture on the Jetson Nano, especially a lot of the HE information.
Whether this is because of missing information from the wireless NIC on the Cisco C9115-AXI or missing functionality in the PEEKREMOTE tunnel back to Wireshark, I don’t know.
People with the knowledge of this can enlighten this later.
My goal with this article is to point out the difference in captured data between these two methods

Update: I have overseen the information under Extended flags. This is some information from Niclas Darchis after I published this blog:
this extended flags ax flag and number of spatial streams is precisely the fix I put into wireshark 3.4 for peekremote. This extended flag field is where we could add things if we are to add to peekremote protocol

Capturing OFDMA frames
In 802.11ax (WiFi6) there are also OFDMA frames, where data from different sources or to different destinations are sent in parallel on subchannels or resource units (RU). The Jetson Nano is capable of capturing those frames allocated to specific associations ID (AID). Look at my blog to find articles on how this can be done.
I do not know any methods of doing this on an AP for the moment

Remark
In this example, I have captured one specific frame which is not aggregated. Different types of frames have different additional radiotap information added to them, and this example does not cover all types of frames

Summarizing
To summarize my findings we can split it into two parts; the information which is added to the captured data and the data frame itself.

• The capture from the Cisco C9115-AXI is missing a lot of important information in the Radiotap header and 802.11 radio information compared to the Jetson Nano. For those who use wireless captures in managing and troubleshooting networks, this is a key element to be aware off
  
• The Data part of the captures, the MAC header and the rest of the data is equal on the two methods

I really hope this quality of the captured data from the Cisco AP in sniffer mode improves when the 802.11ax technology matures because using an AP on a remote location as a sniffer device is an important feature in the wireless engineers daily work

Conclusion
Wireless capturing is used in many situations and it is important for WiFi professionals to know the different methods and their pros and cons. I have shown in this blog that using a Cisco C9115-AXI AP in sniffer mode has some key flaws compared to using the Jetson Nano with Intel ax-200 NIC.

This test is done in a Cisco test environment
How other vendor’s solutions work is not tested. I doubt they are any better

Attached pcap