Capturing 802.11ax with the Jetson Nano

The NVIDIA Jetson Nano Developer Kit with Intel AX200NGW WiFi6 chips set is one method to make a WIFi6 client. I have some of these.
Earlier today Francois Verges announced at Twitter a method for capturing 802.11ax frames with this kit. And I wasn’t difficult to trigger.

Method:
— Install Wireshark at the Jetson Nano. This link worked well for me, link
— Install aircrack:    sudo apt-get install aircrack-ng
— Start capturing:   sudo airmon-ng start wlan0 36  (the two last digits is the channel)
— Start Wireshark and select the wlan0mon interface.
— Stop capturing (stop monitor mode):  sudo airmon-ng stop wlan0mon
Big thanks to Francois Verges for this method

Test scenario
– Client 1: Jetson Nano with Intel AX200NGW chipset
– Client 2: Samsung S10
– Accesspoint: Cisco Catalyst 9115 in FlexConnect mode
– WLC Cisco Catalyst 9800CL, version 16.12.1, at Workstation
– Sniffer: Jetson Nano with Intel AX200NGW chipset and installed Wireshark version 3.1.1
– WlanPi as the SpeedTest server at the same vlan as the client traffic

Attached to this blog is a pcap with 1000 frames

Downlink direction

As I earlier have blogged about, my network does not do DL OFDMA. The same pattern repeats now. Downlink data are sent from the AP to one client at the time, no parallel downlink transmission.

But the enhancement in this method of capturing versus using a Cisco Catalyst 9115 in sniffer mode is the quality of the Radiotap header and 802.11 Radio Information for the captured frames.
If we look closer at one of the QoS data frames sent from the Ap to the Samsung, opens Radiotap Header and find HE information

Snap of HE Information in Radiotap header

As we can see there are six different HE Data field and each of them explains 802.11ax characteristics.

And even closer into HE Data 3 field
Snap of HE Information Data 4 in Radiotap header
Field to look at is among data rate of MCS8 and LDPC encoding.

So we are able to capture and interpret the single user frame in 802.11ax (HE SU PPDU)

For those of us that like to dig into the PHY layer, this tool gives us much better visibility.

Uplink direction

Nothing is changed in capturing with the Jetson Nano versus using the Cisco Catalyst 9115 in sniffer mode. We are still not able to capture the response to the basic Trigger frame, the UL OFDMA QoS data frame. We see the Basic trigger frame and the MultiSTA BlockAck, not the 802.11ax trigger-based frame (HE TB PPDU). But the network do UL OFDMA.

But it is a very interesting thing to consider. My little network had three associated 802.11ax clients, but one of them was turned in to Sniffer mode. So I have two clients to do SpeedTesting with, but the network does UL OFDMA resource allocation between all three clients. Let us see at the Basic Trigger frame and the MultiSTA Block Ack

Snap of UL OFDMA

As we can see. The AP divides the channel in one 106-tones RU and two 52-tones RUs to AID12 (association-id) number 1, 2 and 3, but it is only AID11 number 1 and 3 that has sent data uplink to the AP. AID number 2 is the client that was associated, but are now a sniffer.

And the spectrum picture from the Sidekick shows this during upload test:

As a conclusion to this: With OFDMA there are a lot of situations where we will have unusual results where the network decide to do resource allocation that from the human minds looks unreasonable.

Conclusion
Using the Jetson Nano with Intel AX200NGW chipset gives better visibility to the Radiotap header and 802.11 Radio Information versus the Cisco Catalyst 9115 in Sniffer mode for the single user frame format in 802.11ax (HE SU PPDU)
But we are still not able to capture UL OFDMA frames (HE TB PPDUs). My network doesn’t do DL OFDMA, so I don’t know whether this method is able to capture multiuser DL OFDMA frames (HE MU PPDUs) or not

Attachment, pcap with 1000 frames
OFDMA test with two clients, but with three associated. 190925-2030, 1000 frames

 

6 thoughts on “Capturing 802.11ax with the Jetson Nano

    • I don’t think it is possible. I have not heard about it. For now, I believe this is the only solution to capture frames inside a RU based on either MU PPDU or Tigger-Based PPDU frame transmission

      Like

Leave a comment