The introduction of the OFDMA feature in the 802.11ax standard gives us packet analyzers some challenges regarding wireless capturing. It is two aspects that are challenging. Capture data inside specific resource units (RUs) and how to visualize it in a graphic user interface (GUI) if we can capture several parallel transmissions.
Some experts have said it would be very difficult to do multi-user capturing, but I have always thought it should be possible to do this
It is basically the same transmission method as we have used for over 20 years. It is some new frame formats and the OFDM subcarriers are split between several stations, but that’s all (almost).

 

Wireless capturing in single-user frame transmission

In the case of single-user 802.11 transmission and the half-duplex structure of 802.11, only one station (STA) is transmitting at each time. It is therefore never more than one frame in the air at the time, assuming there is no collision, and the full contents (or channel)  is used by every receiving station.
The wireless capturing device will capture each and every frame, one after another and show it in the UI of our packet analyzer software.
A normal capture of single-user transmission (TxOP) looks like this:

A very important aspect of single-user frames is that the unique identifier of each frame are the MAC addresses from the MAC-header of an 802.11 frame

 

Multi-user frames in OFDMA

When the AP, or the controller, decides to use OFDMA during transmission it introduces two new frame types.

• For QoS data frames downlink from the AP to several stations (DL OFDMA), the AP uses a frame format called HE MU PPDU (the multi-user frame format).
• For QoS data frames uplink from several stations to the AP (UL OFDMA), they use a frame format called HE TB PPDU (the trigger-based frame format).
• I have several blog articles where those are explained in more detail.

For the stations to be able to receive its data in their assigned resource unit (RU) they have to look and decode a specific field during a transmission.

• For DL ODFMA, all 802.11ax station in the BSS has to look into the HE-SIG-B field of the pre-HE preamble (the HE physical header) in the downlink multi-user frame and see if the AP sends data to him.
• For UL OFDMA, the station has to use information in the previously sent Basic Trigger frame to find out if he is allowed to send its data, and in which RU and with which characteristics.
• And the new unique value to identify each station during resource allocation is the association ID (AID), in which each station is assigned during the association process to the BSS.
  Let us take a closer look

 

Downlink QoS data frame in the multi-user frame format

The downlink multi-user frame format (HE MU PPDU), used for DL OFDMA, looks like this (simplified).

I have a blog article with a deep-dive of this multi-user frame.

The HE-SIG-B field in the HE preamble contains a Common field and one or more User Specific field, one for each of the stations that will receive data. The frame in this picture above contains one Common field, a User Specific fields for the station AID1 and a User Specific field for the station AID2. The frame can contain several other User Specific fields, but those have other meanings.

The Common field contains information on how the channel is subdivided for the data (A-MPDU) part of it. It is a bit pattern and in the frame above this pattern tells that the channel is subdivided in two times 106-tones RUs.

The User Specific field for each of the receiving station contains:
– The receiving stations association ID (AID)
– Number of spatial streams
– Use of transmit beamforming
– The MCS
– The use of Dual Carrier Modulation (DCM) or not
– The coding scheme, BCC or LDPC

Based on this information, the station which will receive data recognize its association ID (AID), see which type of RU (how many tones/subcarriers) is used, where the RU is in the frequency band (which tones/subcarriers), the MCS, numbers of spatial streams and coding scheme for its receiving data. And it will only listen to the assigned RU during A-MPDU reception.

One very important aspect for us to learn is that this is only one (1) frame transmission, sent from the AP. It is accidentally set up in a way where several independent A-MPDUs (data payloads) are modulated into specific subcarriers (RUs).

 

How to do wireless capturing of DL QoS ODFMA frames

For wireless capturing, we can use the same method as the receiving station does for its receiving of the A-MPDU.
But we must tell the sniffer to capture on specific association ID (AID) because our packet analyzer software is not capable to show several payloads in parallel, yet.
If the sniffer knows which AID it should capture, it uses the information from each frame HE-SIG-B field and captures on the assigned RU. This can change from frame to frame

The Intel AX200 NIC has the ability to capture frames on specific AIDs. Tim Higgins has sent me information on how this could be done on the NVIDIA Jetson Nano developer kit.

John Kilpatrick has a blog on how to build this device.
Francois Verges has a blog on how to do remote capturing on the same device.

The method is to start capturing and type this command into a terminal window, or via SSH, to the sniffer device

echo 0 00:00:00:00:00:00 > /sys/kernel/debug/iwlwifi/*/iwlmvm/he_sniffer_params

The first parameter is the value of the AID you want to capture.
The second parameter is the MAC address of a specific AP/BSS. You only need this in an environment where there are multiple APs using OFDMA.
If you want to capture on several AIDs, just toggle between the AIDs in your BSS. But remember that you can only capture frames from one AID at the time.

You will with this method capture all single-user frames and the downlink multi-user frames for the AID you have selected.

To examine the captured multi-user frames in your packet analyzer software, you can either use a display filter for MU-frames (in Wireshark).

radiotap.he.data_1.ppdu_format == 0x2

Or, in Wireshark,  make a column out of the same display filter. You find it in the RadioTap Header/ HE Information/ HE Data 1/ PPDU_ format.

 

How to find the Association ID (AID)?
This a very good question and is an area of further development.

If we want to capture and analyze a specific station with a specific MAC address in an OFDMA environment we need to know the association ID (AID) to this station. And a station AID will change when it roams to another BSS, or it re-associate to the BSS.
I have not a very good answer now, but this is some suggestions:

• The association response frame when the station (re-) associate to the BSS
• VHT/HE NDP Announcement frames, there are two types
  • The destination address is the broadcast address
    • Those contain STA Info with all stations in the BSS (STA List)
    • No MAC addresses
  • The destination address is a unicast address
    • Those contain both the STA MAC address (MAC header) and the AID (STA List)
• Basic Trigger frame that precedes the UL OFDMA transmission
  • This contains the AIDs (User Info field) for the next UL OFDMA-transmission
  • No MAC address of the AIDs
• Multi-STA BlockAcknowledgment frame, which ends a UL OFDMA transmission
  • This contains the AIDs (Per AID TID Info) for the received UL OFDMA-transmission
  • No MAC address of the AIDs
• Capture some MU-frames and use either aliasing or write the connection between the MAC addresses and the AIDs on a paper
• Look into the wireless controller or in the CLI of the AP. I have not tested this.

 

Very important remark
This method captures only the downlink multi-user frame in the HE MU PPDU format. The BlockAcks for those frames are sent uplink in a HE trigger format, similar to UL OFDMA

Uplink QoS frame in the HE Trigger format

The HE TB PPDU ( trigger-based) frame format is used when the stations (clients) sends data frame uplink to the AP in a multi-user format (UL OFDMA). I have several blog articles explaining this.

Briefly, it is like this:

• the AP sends the Basic Trigger frame as a control type of frame. This frame contains information for which and how the clients (AIDs) shall send their uplink data.
• the clients (AIDs) send their data in their assigned RU in the HE TB PPDU format.The HE TB PPDU frame format looks like this (simplified) when one of the stations sends its data in a specific RU

Unlike DL OFDMA, where the AP sends one frame containing all the different payloads (A-MPDUs), in UL ODFMA each station (client) sends its own frame.
The AP will receive several frames in parallel and has to decode each and every one. But the payload (A-MPDU) from each station is into its own resource unit. This blog article explains the RF during UL OFDMA

BlockAcknowledment during DL OFDMA
The BlockAcknowledgment for the downlink QoS data frames in DL OFDMA is sent uplink in this trigger-based format, just like payloads during UL OFDMA.
The first MPDU in the A-MPDU during DL ODFMA contains the trigger information for the BlockAck.
Look at the Wireshark picture above showing the captured multi-user frames during DL OFDMA. The first MPDU, before the QoS MPDUs, is the trigger information for the uplink BlockAck

 

Are we able to capture uplink multi-user frames in the HE TB PPDU frame format?
I don’t know any methods for capturing this trigger-based frame yet.
This blog explains the current status of capturing UL OFDMA, where we capture the Basic Trigger frame and the Multi-STA BlockAck. And based on the information in these two frames we can interpret the trigger-based QoS frames in between.

There are to main challenges with capturing uplink trigger-based frames (my opinions)

• The information the sniffer needs for capturing the uplink data frame for a particular AID is in the previous Basic Trigger frame from the AP. So the sniffer needs processor capabilities and code to do this.
• Multiple frames in the RF spectrum. It is only the AP in an 802.11ax OFDMA environment that shall receive those types of frames and it is built to do it. Our capturing wireless NIC is build to be a wireless NIC in, what the 802.11ax draft calls, a non-AP station.
• It is possible to use APs in sniffer mode. But still, we need a system to visualize selected AIDs in a packet analyzer

 

Permissions while using the echo command

When I use my NVIDIA Jetson Nano as the capturing device and sends the echo command to the sniffer, a failure message appears regarding permissions.
It is because of some permission rules in the OS of the Jetson Nano.
I am not very familiar with Ubuntu, but Tim has sent me this recipe

In terminal (or over SSH)
sudo chmod a+rx /sys/kernel/debug
sudo chmod a+rx /sys/kernel/debug/iwlwifi
sudo chmod a+rx /sys/kernel/debug/iwlwifi/0000:03:00.0
sudo chmod a+rx /sys/kernel/debug/iwlwifi/0000:03:00.0/iwlmvm
sudo chmod a+rwx /sys/kernel/debug/iwlwifi/0000:03:00.0/iwlmvm/he_sniffer_params

You have to check the file path and the name on the “0000:03:00.0” directory. It could be different. He sent this as a script, but I have to type each and every line separately.
This has to be done each time the sniffer reboots.

 

Triggering of the UL and DL OFDMA process

I have a lab network with a Cisco Catalyst 9115 access point and the Catalyst 9800CL wireless controller, three clients, and two WlanPi as the SpeedTest server.

The AP (and the controller) enables the UL OFDMA feature all the time, but it is a challenge to trigger the DL OFDMA feature. I must generate a lot of traffic and still, it’s difficult to trigger the DL OFDMA. Very often my network does downlink single-user OFDM on 802.11ax frame format instead of DL OFDMA.
Why: I think Cisco is still developing this feature and it will become better in future code releases 

I use SpeedTest against WlanPi as my test method because it generates a lot of traffic and it is easy to see in a spectrum analyzer whether the network does OFDMA or not.

Summarize

I have explained the theory behind capturing multi-user frames in resource units and how we can capture the downlink multi-user frame in DL OFDMA with the Jetson Nano.
And maybe we can be able to capture uplink trigger-based frames soon.

 

A big thank you to Tim Higgens

I have to send a big thank you to Tim Higgens. It is Tom who told me how to capture multi-user frames.

 

 

 

 

 

 

My previous blog post was on how the RF spectrum looks like during a UL ODFMA transmission.

This article is about the DL OFDMA transmission. The DL ODFMA transmission can be preceded by an MU-RTS (multi-user request to send) and CTS (clear-to-send). I keep it to a later article.

 

The Acknowledgment process
The most efficient mechanism to get the 802.11 acknowledgments back from the STAs (non-Ap STA) during DL OFDMA is to include a Trigger frame as the first MPDU in the A-MPDU.
The STAs will respond with a BlockAck in a HE TB PPDU immediately and in parallel. Just like the UL OFDMA process.
This picture (found on the internet) shows this process

This is a new method of sending the 802.11 acknowledgment. For 20 years this 802.11 acknowledgment frame has been sent in non-HT format as a Control frame on a mandatory data rate. In 802.11ax and DL OFDMA is one of the options is to send it in a subdivided trigger-based frame.
I will explain it in a later article.

 

A short summary of DL OFDMA
– In this example, the AP will data downlink to two STAs (clients)
– The AP decides to subdivide the 20MHz channel into two 106-tones RUs and send the data (payload) til client1 (AID1) in the lower 106-tones RU and the data(payload) to client2 (AID2) in the higher 106-tones RU.
– This receiving STAs sends their acknowledgment as BlockAck inside their assigned RU, based on the content in the Trigger frame, uplink to the AP in a TB PPDU format

 

The DL ODFMA frame
The frame been used when sending data down to multiple non-AP STAs in parallel is called MU-PPDU (multi-user). I have a deep-dive article on this.
Basically, the transmitting procedure is like this:
– First the legacy preamble
– The HE-preamble. It contains the HE-SIG-B field with information about the resource allocation for the rest of the frame.  It tells each receiving STA which RU the STA will receive its data on.
– The HE short and long training symbols
– The A-MPDU to each non-AP STA in their assigned RU, where the first MDPU is the Trigger information for Block Acknowledgment

From the perspective of the AP it looks like this:

 

The non-AP STA, let’s say AID1, will see in the HE-SIG-B field that the data to AID1 is sent in the lower 106-tones RU. The STA with AID1 will therefore only look at the subcarriers that are assigned for him, both short/long training fields and the data.
So from the perspective of AID1, the transmission looks like this:

 

 

BlockAcknowledgment
The receiving STA will use the Trigger information from the first MPDU in the A-MPDU in the downlink data frame to build the frame that sends back the BlockAck. The frame type used for this is called HE TB PPDU and is the same method as used with UL OFDMA. UL OFDMA is explained in this article.

In this example, the receiving STA sends their BlockAck like this:

 

Just like any other 802.11 frames, it starts with preambles using the full channel. And the BlockAck information is sent in their assigned RU.

From the AP perspective, those transmissions will be received in parallel.

This was explained in my previous article

 

Summarize
This is DL ODFMA briefly explained

 

Remarks
A friend of mine has sent me some packet captures with the Multi-User frame down to several clients. He uses SOHO-routers in beta code for this.
He has explained how he does it and today I was able to capture MU-PPDU from a Cisco Catalyst 9115 access point down to a Samsung S10.

I will put together an article on “how to capture DL OFDMA”

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

During 802.11ax UL OFDMA magic happens in the RF space. What were RF collisions before is with 802.11ax normal behavior.

I will in this blog briefly explain what happens in the RF space during UL OFDMA.
I recommend reading one of the previous articles where I explain what it looks like in Wireshark.
I will simplify it so it is two clients that will send their data uplink in two different 106-tones RU

A short summary of the UL OFDMA process
– The AP sends a Basic Trigger frame, as a broadcast frame, in the legacy frame format at one of the mandatory rates
– STAs (clients) that are announced in the Basic Trigger frame sends their data uplink to the AP in parallel
— The AP sends a broadcast Multi-STA BlockAck frame to acknowledgment the received data frames

 

The Basic Trigger frame
This is the frame that is sent by the AP to solicits an uplink triggered frame from one or multiple STAs. This frame is a control type of frame and is sent at one of the mandatory data rates.
The information in the Common Info field and the User Info field is used by the STAs to build their uplink data frames
It uses the full channel, 20MHz. A visualization of this could be like this

 

The UL OFDMA data frame
The STAs (AID1 and AID2) will receive the Basic Trigger frame, interpret it and start sending their data in a frame format called Trigger Based frame (HE TB PPDU).

Each and every 802.11 frame has to start with the legacy preamble for backward compatibility, then these two have to send the pre-HE preamble because it is a 802.11ax frame. These two preambles are sent at the legacy subcarrier format, with 48 and 52 data subcarriers with 312.5KHz spacing. When this is done each STA will send the HE Short Training fields and the HE Long Training fields at the 802.11ax subcarriers format and at each STAs assigned subcarriers. And at last, each STA will send their data (A-MPDU) on their assigned subcarriers.
This transmission will start, from both STAs, a SIFS after receiving the Basic Trigger frame. A visualization of this is like this.

As we see, the legacy preamble and the pre-HE preamble uses the full channel and the HE-training fields and the A-MPDU is sent at each STAs assigned RU

If we combine these into one picture it looks like this, from the perspective of the AP

In legacy 802.11 (a,n and ac) this is a collision in the RF domain and the AP is not able to decode it correctly.
In 802.11 ax, the AP knows what is will receive and the legacy preamble of those two transmissions is equal because of the STAs (AID1 and AID2) uses information from the Basic Trigger frame to build the legacy preamble.
So the AP has basically one task: to use all its skills to prepare itself to receive a Multiple Input transmission (from MIMO). Spatial diversity, radio chains, memory, processor power, etc
And during the reception of the HE-training fields and the data (A-MPDU) the AP knows the setup (subcarriers, MCS, spatial streams, guard interval and so on).

And this works. My lab network based on Cisco equipment does UL OFDMA

 

The Multi-STA BlockAck
When the AP has received the data frame from the STAs, it acknowledgment the data frames with the Multi-STA BlockACK. This is a control frame sent at any of the basic rates, but it is usually sent at a mandatory data rate. Since it is sent at a basic rate it uses the full channel. Visualization like this

 

Summarize
This is UL ODFMA briefly explained

 

I am launching the WiFi AirTime Calculator.

WiFi Community, feel free to test it and use it for self-study or during the education of your colleagues, clients or other

You find more information here, in the top menu or in the picture on the right-hand side

During WLPC_EU we had an 802.11ax after-party where we tried to make OFDMA functioning with different vendors AP and we got someone to do OFDMA. But we were kicked out of the meeting room before we got good results.

I have a network at home that does UL ODFMA, but it does not do DL OFDMA.

I have a packet capture of the UL OFDMA transmission and will explain it in this blog.

Theory
A figure from the IEEE 802.11ax draft 4.0 tells this about UL OFDMA

If we look at the last three frames
— the AP sends a Trigger frame to the clients
— the clients (STAs) sends it data uplink to the AP in parallel
— the AP acknowledges the frames

Test network
My test network looks like this (very simple picture)

What I do, briefly explained
– associate two clients, a Samsung S10 and a Jetson Nano,  to the Cisco 9115 AP controlled by the Cisco Catalyst 9800CL controller running version 16.12.0. The AP is in FlexConnect mode
— the clients run Speedtest against a WlanPi. Speedtest is started simultaneously on both clients
— a Jetson Nano in sniffer mode does packet capturing
— a Windows client running Wireshark receives the captures frames via sshdump
— a client running Ekahau ESS with RTFM (Real Time Frequency Monitor) with Sidekick connected

A prefer doing Speedtest against the WlanPi because it does a finite period of ping/jitter testing, download test, and upload test. In this way, it’s easier to see how the spectrum changes, instead of doing any kind of iPerf-test.

Spectrum picture

What is this
— a 20 MHz wide spectrum picture during the Speedtest upload test
— one client using a 106-tone RU (Resource unit) in the lower half
— one client using a 52-tone RU in the upper part
— a part of the spectrum with lower utilization

 

Packet analysis
It is still no available method that is able to capture frames that have data in subdivided RUs, so we capture only two packets during a UL OFDMA transmission. The standard describes the use of protection with MU-RTS and CTS, but my network doesn’t use protection. The MU-RTS and CTS are explained in a previous blogpost .
The captured frames are the Basic Trigger frame and the Multi-STA BlockACK

Basic Trigger frame
This is a new control frame the 802.11ax standard uses to trigger an uplink transmission from its associated clients. Wireshark is able to decode it, while Omnipeek doesn’ do it. I have explained the frame format for this frame in the MU-RTS/CTS blogpost, but here is a short recap. The basic Trigger frame consists of:
— MAC header
— Common Info Field
— One or more User Info field

Basis Trigger frame, the MAC header

The most important notice is that the Basic Trigger frame is a broadcast frame (RA= ff:ff….), sent from the TA with the BSSID address. The 9115 notation is because I have entered the AP MAC address into the ethers file in Wireshark.

Common Info field

The Common Info field is information to the clients that are addressed in the User Info field on how they shall build the frame for the uplink data. The content in the Common Info field is outside the scope of this article.

Basic Trigger frame, User Info field

This Basic Trigger frame has three User Info fields, meaning there are three clients (STAs) that are been allocated RUs for their uplink data.

If we open the two first User Info fields, it contains this.

In basic text, it says this for the first User Info field: Client (STA) with association-id 0x001 has been allocated resource unit number 53, and it should use coding type LDPC with MCS8 and 2 spatial streams.
Resource unit number 53 is the 106-tone RU in the lower band of this 20MHz channel.

The next User Info field says that the client (STA) with association-id 0x002 has been allocated resource unit number 39, and it should use coding type LDPC with MCS0 and  2 spatial streams.
Resource unit number 39 is the 52-tone RU right after the middle off this 20MHz channel.
Why MCS0. The controller has three clients in its association table so it allocates RUs to all clients, even if some of them have nothing to send. This is the first code version to Cisco that does UL OFDMA and its scheduling process will be better in later versions.

For client no 3, not shown in a picture
Client (STA) with association-id 0x003 has been allocated resource unit number 40. Resource unit number 40 is the last 52-tone RU in this 20MHz channel.

UL OFDMA data frame
The data frames are not captured. It is amazing stuff that happens during this transmission of the data frames but it will be a topic in another blog post.
In short: Clients send it data in their assigned RUs uplink to the AP.

Multi-STA BlockAck
When the AP has received and decoded the uplink data frames it will send an acknowledgment back to the clients. The AP uses a new Block Acknowledgment frame called Multi-Station BlockAcknowledgement, Multi-STA BlockAck. This frame is sent as a broadcast frame.

Multi-STA BlockAck MAC-header

The figure shows the first part of the Multi-STA BlockAck. The Receiver address is the broadcast address and the Transmitter address is the APs MAC address or BSSID.
This frame is sent straight after the data frames because the Block Ack policy requires an Immediate Acknowledgment and the type of frame is Multi-STA BlockAck.

Per AID Info field
There is three different Per AID TID Info field. This means that the Multi-STA BlockAck sends an acknowledgment to three clients. The first one

This is the BlockAck to association-id 0x001and has a starting sequence number of 3562. Each and every A-MSDU or MSDU that is aggregated into the A-MPDU have their sequence number in their MAC header. The number 3562 is the first sequence number that the AP has received in the data frame transmission.
When the AP receives those aggregated frames it makes what is called a scoreboard. This scoreboard is a view of which frames the AP has successfully received.
In the BlockAck the AP show which sequence number it expects to receive in the next transmission. In the figure, the sequence number of the next frame it expects to receive is 3582. This means that the AP has successfully received sequence number 3562 to 3581 in this transmission.
It could happen that the client has sent more MSDU/A-MSDUs, but the AP has not successfully received all. The AP will only acknowledgment those that are successfully received and the transmitter has to resend some of them
Example: Let us assume that the client has sent sequence number 3562 to 3590. Since the AP has the next expected sequence number to be 3582, the client has to retransmit sequence number 3582 to 3590.

Remark
The 802.11 standards until 802.11ax use mainly MAC addresses as unique identifiers for the different STAs, including the AP.
The 802.11ax amendment uses the association-id to the client as the unique identifier in many of the frames. We see this both in the Basic Trigger frame and the Multi-STA BlockAck.

Summarize
The Basic Trigger frame tells three different clients to do UL OFDMA, the first one with the lower 106-tone RU (53), the next two in the two higher 52-tone RUs (39 and 40).
We are not able to capture the data frames.
The Multi-STA BlockAck acknowledgments successfully received sequence numbers in the aggregated data frame from the three clients.
The client that is allocated the first 52-tone RU is not present
The spectrum picture confirms what the packet capture tells.

 

Conclusion
UL ODFMA is working in my network, and it is possible to capture and interpret the transmission. The data frames, that are sent in subdivided RUs, is not possible to capture. But we can interpret and understand the UL OFDMA transmission by looking at the Basic Trigger frame and the Multi-STA BlockAck

 

Wiresharkfilter

 

My previous article was on how to do wireless capturing on a Jetson Nano, with a big external screen connected to either the HDMI or the Display outputs of the Jetson Nano. And with connected external mouse and keyboard

But what if you want to use favorite packet analyzer on your preferred client where you have all your configured filters, profiles, aliases and so on.

I have tested different methods to do remote connections to the Jetson Nano, either by VNC or SSH. With VNC it connects but I  get no picture. With SSH it connects and I am able to start capturing, but I struggle to start Wireshark.

I have bought a small 5″ screen to my Jetson Nano, but it is not very convenient to do packet analyzes on that screen. And I have to use both a keyboard and a mouse. But it could be used during packet captures.

Now I have found a method that works well for me. This includes the Jetson Nano with the small screen, an external mouse at the Jetson Nano and a connection to my preferred client. This method is very simple and has many improvement opportunities, but it is a good start

Basic setup
Use a cross-connect ethernet cable between your client and the Jetson Nano ethernet NICs and use fixed ip addresses on both devices. I prefer to use a /30 network

Jetson Nano
Since I don’t found any suitable box for the screen on the internet, I went to a local grocery store and bought a simple plastic box. Actually a lunchbox.
Some small work with a knife, a drill and some screws and this is the result.

Connect an external mouse to the Jetson Nano. To get rid of the keyboard some changes must be done in the OS of the Jetson Nano. The first one is to skip logging on when power on and the other is to make sure the screen saver doesn’t turn on. You must use a keyboard to change these settings.
– Under System Setting/User accounts: Set the admin user account to automatic login
– System Settings/Brightness and Lock: Set the screen to never  turn off
From now on the screen appear after power on and is always on and no more use of the keyboard.

Now it’s time to do some packet capturing
This is my approach
— set the wireless NIC at the Jetson in monitor mode and start capturing
— start Wireshark to collect the captured frames and save them in pcap-file
— transfer the pcap to your preferred client

• At my client: SSH to the Jetson Nano (10.0.0.1). I use Putty or Secure CRT
  • When connected to the Jetson Nano, use this command to set the wireless NIC in monitor mode and start capturing
    “sudo airmon-ng start wlan0 116”. The last digits are the channel
• At the Jetson Nano,
  • Use the connected mouse to start Wireshark, choose the interface wlan0mon
  • Use the mouse to stop capturing in Wireshark and save the file. Since we don’t use a keyboard we have to save the file by overwriting an existing file.
• Back on the client
  • Copy the pcap from the Jetson Nano to your client with SCP file transfer
    Open Command and use this command:
    scp @:/directory/file
    example for pcap-file “test1” at my setup
    scp nano@10.0.0.1:/home/nano/Documents/Pcaps/test1.pcapng /users/gjermund/downloads/pcaps
    You will, after executing this command, have to type the admin password of the Jetson Nano
  • I have tried to use scp at the Jetson Nano and copying back to my client, but it fails. Probably a firewall issue
  • Now the file is at your client and you can rename the file, if you want, and start examing it in Wireshark

Simple and not very elegant, but it is a method.

A more elegant solution is to have some sort of script on the client that does “all-in-one”, like we do with the WlanPiShark script. But I’m not able to make that.

Francois Verges has tested different capturing setups at the JetysonNano. I summarize it here, mostly at a “note-to-self”. This is not tested by me.

Capturing at 40 MHz
— sudo airmon-ng start wlan 0 100
— sudo ifconfig wlan0mon up
— sudo iw dev wlan0mon set freq 5500 HT+

Capturing at 80 MHz
— sudo airmon-ng start wlan 0 100
— sudo ifconfig wlan0mon up
— sudo iw dev wlan0mon set freq 5500 80MHz

Reference
How to build the Jetson Nano at hypergeek.net

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

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

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

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