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

 

I have tested the new 802.11ax standard lately and I have suspected that the downlink data frames don’t do Multi User OFDMA (DL OFDMA). I have also sent a question regarding this to some WiFi experts, but no one has answered. So, let us use Wireshark and Sidekick to dive into it.

This test is done with public available devices and software. I have not dived into release notes for each device. This is an article where I use Wireshark and Sidekick to examine how things work.

Good references are my previous articles about the OFDMA-process, and my last one was about the DL OFDMA in the same network

My test lab is consisting of
– Cisco Catalyst 9800CL (v16.12.1) wireless controller at Vmware Workstation
– a Cisco Catalyst 9115 AP in FlexConnect mode
– a Cisco Catalyst 9115 AP in SnifferMode
– a Samsung Galaxy S10
– a Nano developer Kit with Intel AX200 NIC with the latest software
– a WlanPi as the SpeedTest server connected to the FlexConnect vlan
– a Windows client with Wireshark v3.0.3 on the native management vlan
– all devices are connected to a Cisco 3560CG-switch.
To make sure that the Sniffer AP could capture the traffic I hide the FlexConnect AP behind a computer and into a box. Just to force mcs rates a little down.

General view of the captured data in Wireshark
– A SpeedTest test with two clients generates 60-80.000 frames
– Very few of the Nano data frames are captured. Maybe my setup should have been even better
– A lot, but not all, Samsung data frames are captured
– During those tests, there are some datastreams downlink and some datastreams uplink.
– All downlink data frames are preceded by RTS and CTS
– All uplink data frames are preceded by a Basic Trigger frame
– The radio tap information inside the AiroPeek/OmniPeek encapsulated IEEE802.11 or the 802.11 Radio Information is not reliable. The data for mcs, coding, datarates and so on are either missing or not valid.

Start Wireshark, associate the clients and then start the SpeedTest against the WlanPi simultaneously on both clients.

Association-id
First step is to associate the two clients to the SSID just to find out which association ID/AID/STA-ID those gets. It is found in the Association Response frames
Wireshark-filter : wlan.fc.type_subtype==1

In the Capabilities Information Element, we will find the Association ID
The Samsung S10 got association ID 0x0003
The Nano got association ID 0x0001

Then I started SpeedTest against the WlanPi from the two clients. First, they do some ping and jitter test, then a download test and at last an upload test. During this test, I had the RTFM-monitor in Ekahau ESS Pro running with Sidekick connected, and I took some snapshots

Download
I have in a previous article done a deep-dive into DL OFMA based on the IEEE802.11ax draft v4. But to sum up:

Theory
-if the AP does DL OFDMA it announces the subdivisions of the band in the PHY header of the data frame. In the HE-SIG-B field there are two subfields:
— HE-SIG-B Common subfield where the RU allocation is announced. In my lab network, it should have announced two times 106 RUs
–HE-SIG-B User content subfield where the AP announces which STA-id that have their data in which RU-allocation. In my lab network, it should announce STA-id 3 to one of the 106 tones RU and STA-id 1 to the another 106 tones RU.

Practice
Here is a small capture during downloading and with a display filter that filters on RTS, CTS, Data frames and Compressed BlockAck

We can differentiate between the clients on the Starting Sequence Number (SSN) from the Compressed BlockAck. Samsung is around 2000 and Nano at 600

Nano (SSN around 600)
-We have captured RTS, CTS and Compressed BlockAck
– The duration field (NAV) in RTS and CTS show approx 5400 µs each time it is a big jump in the BlockAck Starting Sequence Number and a small number, approx 350 µs, when it has been retransmissions of some frames.
– The Time, displayed, in the BlockAck from the Nano is little bit smaller than the NAVs from the previous CTS

Samsung (SSN around 2000)
– We have captured RTS, CTS, some data frames and Compressed BlockAck
– The Duration in RTS and CTS has the same pattern as for the Nano
– If we compare Starting Sequence Number and Missing frames columns against the next BlockAck we can see that there is missing a lot of data frames in the capture

example
-frame 21975 (BlockAck) have acknowledged data frame (Sequence Number, SN) 1912 to data frame SN 1958 from the previous data frame transmissions. Frame SN 1912 as the Starting Sequence Number and frame SN 1959 is the first frame in the next transmission.
– in the next TXOP (frame SN 21981-21986) we have captured data frames SN 1990, SN 1993 and SN 2330.
– but the BlockAck in frame SN 21986 have acknowledged data frame SN 1959 to SN 2004, which means that it has been transmitted a lot of frames that we don’t have captured

To sum up the download test in Wireshark we see that each client gets it data one after another, and not in parallel.

The spectrum picture during the download test looks like this

From my point of view, this is not ODFMA with two times 106 tones RU. Whether it is a HE Multi User frame with one allocated station that has all the 242 subcarriers or a HE Single user frame I’m not able to interpret.

 

Upload test
If we go down in Wireshark to the frames where the upload test is done and filter on Trigger Frames and Multi-STA BlockAck we have this example from Wireshark.

We see consecutive Basis Trigger Frame and Multi-STA BlockAcks

Basic Trigger Frame from the AP
– Ul Length is the parameter that the uplink clients shall set in their Length-bits in the Legacy Signal field
– RU Allocation tells how the channel allocation is during uplink data. Here is it two times 106-tones RU, 53 and 54
-AID12 tells that STA-id 1 (Nano) shall use the lower 106-tone RU and STA-id 3 (Samsung) shall use the upper 106-tone RU

Multi-STA BlockAck
– A Multi-STA BlockAck from the AP sends BlockAck to several clients in parallel.
– in the first frame in the figure, the AP has acknowledged date frame with Sequence Number 1879 (Starting Sequence Number) 1879 from the Nano and the data frame with SN 664 from the Samsung A-id 1 (Nano).
– and the Starting Sequence Number is growing at a steady pace.

This is UL ODFMA according to the IEEE802.11ax draft v4. And my network is not able to capture those multiuser data frames.

The Spectrum picture for the upload test looks like this

The Nano uses subcarrier [-122:-17] and Samsung uses subcarrier [17:122] for the uplink data frames, as we can see clearly. The center subcarriers are not been used during two times 106-tones RUs. But it is a lot of other traffic between the two clients and the AP at the same time that uses the full channel width.
Simultaneously DL OFDM and UL OFDMA
Based on what now have learned and if we do a closer look at the full capture we can see that it is both downlink data frames not using DL OFDMA (using OFDM) and uplink data frames using UL OFDMA throughout the full capture. The difference is the amount of data in uplink versus downlink. If we see at the first Spectrum picture, during SpeedTest downloading,  it is possible to see the UL OFDMA spectrum pattern inside the spectrum for DL OFDM. I have marked it with black boxes

 

Conclusion
Does my network do both DL and UL ODFMA?    Answer: No
Why it is doing UL OFDMA, but not DL OFDMA?  I’ll answer it later if not someone smacks me on my fingers and tells me that I’m wrong

Remarks
This is how I, with my knowledge, is able to interpret a Wireshark capture, supported by Sidekick spectrum analysis.
Maybe I am wrong on some of the things. I attach the full Wireshark capture so others can do the same analysis.
If I’m wrong, please send me a note.

Test OFDMA Sunday Sep.1_gjermund raaen.pcap

This is a blog article on 802.11ax uplink OFDMA (UL OFDMA) and the control frames that are involved.

According to the IEEE802.11ax draft 4 the UL OFDMA process look like this

The MU-RTS and CTS are optionally and in some Cisco documentation, it says that the MU-RTS/CTS process is not needed. The MU-RTS/CTS process is described in another blog article. And as I say in that article, the MU-RTS/CTS process is not implemented by any vendors yet. And I also say it is better to use legacy RTS/CTS in a mixed environment, maybe.

My test lab is a Cisco Catalyst 9800CL (v16.12.1) wireless controller at Vmware Workstation, a Cisco Catalyst 9115 in FlexConnect mode, a Cisco 9115 in SnifferMode and two clients, a Samsung S10 and a Nano developer Kit with Intel AX200 NIC.

The attached pcap consists of three sessions (TXOP)  of UL OFDMA, each consisting of three frames; Basic Trigger Frame, the Dataframe that is not captured and the Multi-STA ACK (0x0016)

The uplink data that are sent in the HE TB PPDU format is not captured. I’m not sure whether it is a problem with Wireshark or the Cisco 9115 in Sniffer mode, but the information in the Basic Trigger frame and the Multi-STA ACK tells us enough information.

The Basic Trigger frame
Let’s start with the Basic Trigger frame. The Trigger frames are a new type of frames in the 802.11ax standard. The main purpose of the Trigger frames is to allocate resources and solicits one or more uplink HE TB PPDUs transmissions. The Basic Trigger frame is used to solicits the uplink data from one or more non-AP STAs

The frame format for a Trigger frame is like this

The MAC header

The most important thing:
– Control frame, type 1 and subtype 2
– Receiver address is the broadcast address
– Transmitter address is the AP that sends this frame
– Duration; distributing the NAV timer for this TXOP to all STAs in the BSS and on the channel

The Common Info field

The field in the Common Info field is mostly information the non-AP STAs needs to build their frame for the uplink data. But these are something to look at:
– Basic Trigger frame, type 0
– UL Length: This value describes the Length of the uplink frame and shall be put into the Legacy Signal field and Lengths bit
– AP TX Power: The non-AP STA uses this value to calculate its TX-power

The User Info field
The Basic Trigger frame consists of one User Info field pr STAs that will send uplink data. In my lab, the two non-AP STAs (Samsung S10 and Nano Kit) has assigned STA-id (association id) 2 and 3

The most important subfield
– AID12 is the STA-id (association id) for the non-AP STA
– RU Allocation: describe which RU the STA is assigned to
– MCS; the MCS each non-AP STA should use. In this example, those two non-AP STAs will use different MCS. It is the AP that decide this value
– Target RSSI; This is the RSSI the AP want to receive each non-AP STAs uplink transmission at. Each non-AP STA calculate this value based on AP TX power from Common Info field and the RSSI it receives this Trigger frame at

RU Allocation
The RU Allocation subfield along with the UL BW subfield in the Common Info field identifies the size and the location of the RU. Table 9-31g in the IEEE802.11ax draft tells about all the possibilities
Four examples
– 9 times 26 tone RU at 20MHz, values 0-8
– 4 times 52 tone RU at 20MHz, values 37-40
– 2 times 106 tone RU at 20MHz, values 53-54
– 1 time 242 tone RU at 20MHz, value 61

 

 

Multi-STA BlockAck frame

The Multi-STA BlockAck frame is supported in uplink multi-user (UL MU). The BlockAck processes are diverse and I will only show the Multi-STA BlockAck frame

The MAC header is similar to other control frames

Since the Multi-STA BlockAck is sent til two or more non-AP STAs the receiver address (RA) is the broadcast address.

Next is the BA Control field
As we can see it is a Multi-STA BlockAck frame and it ACKs to AID (association ID) 2 and 3. The same AID as the AIDs in the basic Trigger frame

A closer look into one of the AIDs shows

What this basically says is that it has received a lot of A-MSDUs (or A-MPDUs) where the sequence number on the first A-MSDU (A-MPDU) was 3893 and the last one was 3891. The parameter in Missing Frame is the next frame it expects to receive in the next TXOP

If we use the Starting Sequence Number as a column in Wireshark we will see an increasing number for both AIDs

That’s all
If we want to see all the important information on one screen in Wireshark it could look like this

Attachment
Pcap (zip):  UL OFDMA, Basic Trigger Frame and Multi-STA BlockAck.pcapng

The second powerpoint series in my deep dive into the HE/802.11ax protocol is about the Multi User Request to Send (MU-RTS) and Clear to Send (CTS) process.

MU-RTS is one of the new Trigger Frames in the HE process and will be used instead of the legacy RTS.

I’ve have rewritten the slides some times while I have discovered new items during my interpreting of the IEEE802.11ax draft, so the coherence of the slides could have been better.
If I have interpreted it wrong, please tell it to me

My lab is consisting of Cisco equipment and Cisco have not implemented this functionality yet, so nothing is tested in real life.

I hope it useful

 

MU-RTS_CTS_final

 

Last week I got one of my colleagues to install Vmware Workstation and Cisco Catalyst 9800 CL at one of my clients and after 24 hours of configuring and troubleshooting, I finally made it works with APs in FlexConnect mode.

Ciscos documentation on Catalyst 9800 CL and APs in FlexConnect mode is not perfect and I had a lot of challenges during configuration. I have therefore made this recipe for myself and anyone else

First of all. I did not manage to send vlan tagged traffic over the ethernet NIC on my laptop, so I have done a simple configuration on the laptop to make it work.
This network diagram shows all the necessary information about my lab network

With a Cisco Catalyst 9800 CL as the wireless controller all the APs should be in FlexConnect mode and do local switching at the access point. In my lab network I use vlan 1702 as the native vlan for wireless management traffic and vlan 2000 as the user traffic vlan. This vlan is locally switch at the AP and sent towards the switch in vlan 2000
The switch must be configured as a trunk interface. The network diagram shows the configuration on the switch
Remark: Ciscos documentation does not include the native vlan in the allowed vlan list. Since I followed Cisco recommendation it gave my 7 hours extra troubleshooting.

When the network is up and running like the network diagram and it is possible from the controller to ping the management vlan default gateway it time to connect an AP to the switch. The AP should join the controller in Local Mode after some reboots.

When we want to convert APs from Local Mode to FlexConnect Mode at the Catalyst 9800 CL we must use a set of policies
This recipe is for Cisco Catalyst 9800 CL version 16.10.01

My worklist:

1. Configure the WLAN
2. Configure the VLANs
3. Configure a Site Tag (in CLI)
4. Configure a AP profile (AP Join Profile)
5. Configure a Flex Profile
6. Configure a Policy Profile
7. Configure a Policy Tag
8. Tie the AP Profile and the Policy Tag to the APs
   When this is done the AP reboots and joins again in FlexConnect mode
9. Associate a client to the WLAN and test traffic

 

Further on we take it step-by-step

1. Configure WLAN
Configuration, under Tags & Profiles, choose WLANs
Add a new WLAN. It is pretty simple in two tabs, General and Security

2.Configure VLAN 
Configuration, under Layer 2, choose VLAN
Under the tab VLAN, add the vlans in your network (in my network vlan 1702 for management traffic and vlan 2000 for user traffic)

 

3. Configure a Site Tag (in CLI)

configure terminal
wireless tag site SITE.TAG
desc DEFAULT.SITE.TAG
no local-site
flex-profile FLEX.PROFILE
ap-profile AP.PROFILE

Remarks: Cisco documentation configure “no local-site” as the last item. I had to do it first. This is the command that puts the AP in FlexConnect mode.
The names in capital letters are used later

4.Configure a AP Profile
Configuration, under Tags & Profiles, choose AP Join
Add a new AP Join Profile,  write the same name as under Site Tags
Set in the profile name in Name and Description (thats all)
Remarks: I did not find anything about this in the Cisco documentation, but the Syslog said that AP Join profile was absent

5. Configure a Flex Profile 
Configuration, under Tags & Profiles, choose Flex Profile
Add a new Flex profile, use the same Flex Profile name as under Site Tags
Under General: Set in the profile name in Name and Description and the native vlan (management vlan). In my lab: vlan 1702

Under the VLAN tab: add the traffic vlan. In my lab vlan 2000

6. Configure a Policy Profile 
Configuration, under Tags & Profiles, choose Policy Profile
Add a new Policy profile, the chosen name will be used in the next step
Under the tab General: Set in the profile name in Name and Description, set the Status to Enabled and uncheck Central Switching under WLAN Switching Policy. The last one is for locally switching of user traffic at the AP

Under the tab Access Policies, change VLAN/VLAN Group to the traffic VLAN (in my lab vlan 2000)

7. Configure a Policy Tag. Could be done i both CLI and GUI

CLI
wireless tag policy POLICY.TAG
wlan WiFi6 policy POLICY.PROFILE

GUI
Configuration, under Tags & Profiles/ Tags
Add a Policy tag and map the WLAN Profile and the Policy Profile

 

8. Configure AP
Now it’s time to tie those profiles to the AP. The AP is in Local mode when it first joins the controller. When we tie the Profiles to the AP it will reboot and join again in FlexConnect mode.
Configuration, under Wireless, choose Access Points
This first picture shows one AP already in FlexConnect and another in Local Mode (disabled)

Choose the Local Mode AP. Set it to enabled status and choose the configured Policy Tag and Site Tag. It will now, after updating, reboot and rejoin in FlexConnect mode
I had to enable the AP it after rejoining in FlexConnect mode

The status after rejoining. The AP that was in FlexConnect is disabled in this example

9. Connect a client
Now is the moment of truth.
Enable WiFi on your client and connect (associate) it to the WLAN. Check your connected ip address and test traffic to the internet or other services

Closing remarks
When you configure you have to use the “Update and Apply to Device”. This button is in the lower right corner in each window. Always wait for some time before the changes is applied to the devices
The Syslog under Troubleshooting is a very good help during this process
And of course, constructive feedbacks are welcome

 

Other references
It is other blogs that do research into the same area. Two of them are

• cleartosend.net
• wifininjas.net

 

 

 

I mentioned in my latest blogarticle that I have read the book “Next Generation Wireless LANs” second edition from Eldad Perahia and Robert Stacy. This is fantastic book that goes way beyonds study material for the CWAP-certification .

To memorize this bit-by-bit stuff I have made myself a ODFM, HT and VHT PHY cheat sheet

Remark: This is a 50% product and in A3 format.

Constructive feedback are welcome

Downloadable file (pdf): OFDM, HT and VHT PHY Reference cheat sheets