Modern internet browsers (such as Chrome, Safari, Firefox) are equipped with advanced developer tools. We can actually leverage some of these tools to take a look at which API calls are made behind the scene when you view or modify settings of your favourite Wi-Fi network cloud plarform.

To illustrate this feature, we will make a simple change on our Mist dashboard while trying to see which API calls are made in the background. We will explain how to do it in Safari and Google Chrome.

If you want to see how it work in a video, here is how it works on Safari:

First you need to enable the developer menu to display under Safari's preferences:

At this point, you should be able to click on the "Develop" menu in Safari's menu bar. From the "Develop" menu and open the "Show Web Inspector":

Once the "Web Inspector" panel is opened, it should look like this:

From there, you can navigate to the "Network" Tab in order to display all the network related information:

At this point, it can be a good idea to filter the different network request to only show the ones made to the API you are studying. In this case, since we are using Mist, we can filter by using "api.mist.com" as follow:

Then, you can go ahead and perform the changes you want to study. In my case, I renamed an AP I have here in my lab to "AP-SemFio-AP04". Before clicking on "Save" to apply the changes on the Mist Cloud, I actually cleared all the existing network requests displayed under the web inspector panel: 

You will then start from a brand new list of network requests and it will be easier to find the API Call you are looking for. I then went ahead and applied my changes. It generated a few API calls in the background and I was able to pin point the one used to rename the AP:

In this image above you can see that the following information is available in the "Header" section:

• Status of the API response : 200 OK in this case
• Method used for the request: PUT
• URL used for the request: https://api.mist.com/api/v1/sites/1a13f6c2-3186-418f-8ca9-016fa4ac9ee7/devices/00000000-0000-0000-1000-5c5b352e4e1b

If you navigate to the "Preview" section, and select "Request" in the drop down menu located on the right side, you will be able to see the body of the API Call:

If you look into it, you should be able to see the new name of the AP.
Moreover, it will give you an idea of what type of data is expected by the Mist cloud. So when you build your API calls in your scripts, you could make sure that you are sending the appropriate data.

If you select "Response" in the drop down menu located on the right side, then you will be able to see the content of the response:

As you can see, the name of the AP has been updated successfully.
Moreover, you can study which pieces of information are sent back from the Mist cloud. You could be able to re-use some of them in your scripts.

In Google Chrome, the developer tools are available by default by clicking under the "View" menu and selecting "Developer" / "Developer Tools":

Once the developer tools panel is open, you should see something like this:

Note that in my case, the panel is located at the bottom of the Chrome page. By default, the panel will be located on the right side of the Chrome page. You can adjust where you want it to be.

You have the same search field to filter out only the API calls you are studying, In my case, I added the "api.mist.com" filter:

I then performed the same change as the one I did on Safari (renamed an AP to SemFio-AP-04). Before applying the changes, you can also clear the output by clicking the following icon:

We are then ready to apply the changes and send the API Call. You can then find the API Call you want to study from the "Network" tab:

When you click on the API Call, a new panel will open displaying a few sections. In the "Headers" section, you will be able to retrieve of lot of information:

In this image above you can see that the following information is available in the "Headers" section:

• Status code of the API response : 200 OK 
• Method used for the request: PUT
• URL used for the request: https://api.mist.com/api/v1/sites/1a13f6c2-3186-418f-8ca9-016fa4ac9ee7/devices/00000000-0000-0000-1000-5c5b352e4e1b
• The Request payload: you can see that the new name is set to SemFio-AP-04

In the "Response" section, you will be able to see the response content:

Somewhere in the response, you will be able to see the new name, confirming that everything worked well.

I hope that this article will be useful for you. You should be able to do the same thing in other internet browser if they have some sort of developer tools.

Thank you for reading!

​
written by François Vergès

In a first video, I explain everything you need to create your first API call to the Mist system dashboard. In order to make this API call, I use an application called Postman. Postman allows you to build your API calls in a very easy way. This is useful to test the API calls, make sure they work and analyze the results we get from the Mist dashboard.

Then, in a second video, I explain how to include the same API call within a Python script. I then go on and go over a script used to modify the name of an access point using an API PUT call.

​Here is the script used to send the GET API call and list the access points available in my lab:

Here is the script used to change the name of an access point based on its MAC address:

I hope that these scripts will be useful to you! 

François Vergès

In this article, we will talk about the important of assessing the Wi-Fi in a warehouse and talk about specificities brought by these type of environments.

The main challenge of a warehouse is the fact that the environment can be moving a lot. Here is a list of changes I have seen happening in warehouses:

• Change is the type of goods stocked in the racks (one day it is cloth, the next day it's car break pads)
• Change in the rack layout (new racks might be introduced to store more goods)
• Dynamic creation of zone of attenuation (especially in the loading docks areas, piles of goods might be temporary stored somewhere before being moved)
• Addition of a mezzanine or mezzanine levels

The building structure is also a challenge in itself. Warehouses typically have high ceilings. This means that a proper Wi-Fi design is required in order to make sure that the proper antennas are being used. Part of the building structure is metal. You will find a lot of metal in a warehouse. This metal will tend to reflect Wi-Fi signals. This is not necessary a bad thing but it can drastically change how the signal will propagate throughout the environment. So you cannot expect the signal propagation within an aisle to be the same as the signal propagation in an open space. To be sure, the signal needs to be measured in order to assess the real signal propagation.

All of these might impact the Wi-Fi service and negatively impact the user experience and productivity of the warehouse.

More recently, I have also seen a lot of device changes in warehouses. We start to see the introduction of IoT devices such as AGV (Automated Guided Vehicles), robots, asset tracking tags or machine monitoring tools that connect to the enterprise warehouse Wi-Fi network. Moreover, the more traditional devices might get replaced (RF barcode scanners, lift truck embedded computers...). All these changes might introduce new requirements and this might require to adjust the initial Wi-Fi design.

I recently worked for a customer that introduced VoIP Wi-Fi phones into their environment. Since the initial design wasn't done to meet VoIP requirements, the user experience was poor. We had to assess the current Wi-Fi network and re-adjust it in order to make sure that VoIP would work over the Warehouse Wi-Fi.

When assessing the Wi-Fi network of a warehouse, perform the following:

1. Review the initial design requirements
2. Understand what has changed since the installation of the current Wi-Fi network
3. Study the most critical devices and understand how they operate within the warehouse
4. Perform a site survey in order to validate the RF environment
5. Perform additional spectrum analysis if need be
6. Review the APs (or controller) configurations
7. Work on a plan to improve the current situation
8. Produce a report detailing all the work performed and detailing the recommendations

The first step is to work with the customer to understand what was the Wi-Fi network designed for. What were the initial Wi-Fi requirements? The focus here should be placed on the critical devices used by the users. These critical devices usually drive the design requirements.

At the end of this process, the following questions should be answered:

• Which devices are critical for the business? Which applications do they use?
• Which frequency band(s) are they connecting on?
• Are these critical devices still operating properly over the current Wi-Fi?

Most of the time, customers are requesting an assessment because the Wi-Fi network is not meeting expectations and they are experiencing Wi-Fi issues.
So in order to understand why, we need to understand what has changed since the initial installation. Going back to the previous section. A lot can change in a warehouse environment and negatively impact the Wi-Fi service.
​Once you have understood what has changed, you can define, alongside your customer, a new set of Wi-Fi requirements. These new Wi-Fi requirements can take into account any changes made on the client devices and applications used in the warehouse.

Here are example of a couple of questions you could ask to understand what has changed:

• Are you experiencing Wi-Fi issues everywhere in the warehouse?
• Were new racks installed? Was a new mezzanine floor added?
• Were new devices introduced? (Very common)
• Are you experiencing Wi-Fi issues from specific devices?
• Were new application introduced?

This task is critical. Here we need to select which device (or devices) are critical for the business of our customer and used over the Wi-Fi. Then we will spend time analyzing how they operate.

The following need to be addressed:

• Study how the device "hear" the signal in different sections of the warehouse and on both frequency band (if supported). Compare how the device hears the signal to how well your Sidekick hears the signal. You will then be able to offset the difference in your site survey results and look at the coverage from the critical device standpoint.
• Understand the full Wi-Fi capabilities of the device. This will help you to adjust the requirements and the configurations.
• Understand how the device is configured. Some obvious mis-configurations can be caught there sometimes.
• Validate the drivers installed and the latest drivers available from the manufacturer. It is amazing how a simple Wi-Fi driver update can fix problems. Watch out for multiple versions of drivers being used by different devices.

This task is the most obvious one. You wan to perform a site survey in order to validate the RF environment. In a warehouse environment, you want to focus on making sure that the coverage is good and meeting the requirements.
Make sure that you apply the device offsets calculated previously (cf. section 3) to the results of the site survey in order to analyze the signal from the critical device standpoint.
The site survey will also help you to notice any big problems (maybe an access point is down!).

Unusual interferences can be found in warehouses. So based on the result of the site survey, it might be required to perform additional, localized spectrum analysis to make sure that non-Wi-Fi interference will not impact the Wi-Fi service.

Based on your client device analysis and refinement of the Wi-Fi requirements, you can now analyze the controller configuration to see how it could be improved.

Here is a list of items to look at:

• Configuration of the SSID profiles (Frequency band, 802.11k/r, security, Qos...)
• Configuration of the Access Point radios (Tx Powers, Channels)
• Configurations of AP Groups and RF Profiles

With the results of the site survey, spectrum analysis and the analysis of the controller configurations, you should be able to work on a plan to improve the current Wi-Fi network.
Here we are talking about configuration changes you might be able to implement in order to improve the performance of the critical devices. More important changes might be recommended in the report if, for instance, access points need to be moved, removed or added.

Once this plan is implemented, it is a good idea to re-do a site survey in order to confirm that the changes improved the situation. I also like to perform application testing with my customer in order to evaluate the user experience and make sure that it has been improved and meeting the expectations.

This task is very important for us. It is also very important for your customer so they can have all the relevant information.

The report should include the following information:

• Results of the critical device analysis
• Results of the site survey (RF)
• Results of the spectrum analysis
• Results of the controller (or APs) configuration analysis
• List of changes made on the infrastructure
• Results of any application testing performed
• List of recommendations

It is also a good opportunity to transfer other documents to your customers. We like to provide the additional following documents, alongside the report:

• An spreadsheet detailing all configuration changes
• Device manufacturer documentations
• Videos of any spectrum activity of non-Wi-Fi interferences
• Pictures and videos of the device and application testing
• Ekahau site survey source files
• Pictures of each Access Points located in the warehouse

It is important to assess the Wi-Fi network when new devices or applications are introduced. This is especially true in a warehouse environment. Identify which devices are critical for your environment and make sure that the Wi-Fi is tailored to them. They should, then, operate properly.

Thank you for reading!

François Vergès

When I perform Wi-Fi validation or Wi-Fi assessments, I like to take pictures of the access points and document it later. I also save these pictures and provide them to the customer.

Lately, with the use of the Ekahau survey application on iPad, I have been attaching these pictures to an AP object on my Ekahau project files using the iPad application.

The task of saving these pictures manually can be very time consuming. So I decided to practise my Python skills and create a script that would do it for me.

The script opens an Ekahau project, look for an access point object that has a picture attached to it. It then create a new directory and copy these AP pictures into the new directory. The image is renamed with the name of the AP you have in your Ekahau project.

If you have multiple floorplans in your project, the script will create one sub-directory per floor.

Simply launch the script specifying the name of the Ekahau project:

Feel free to use the script at your own risk :)

​François Vergès

SemFio Networks, alongside Anixter and LHSC, organized the first Wi-Fi Meetup in London ON. The main topic of this first meetup was Wi-Fi 6.

The event was very nice and attracted network Engineers supporting large wireless infrastructure in London. We even had a couple of guys coming from the GTA. We will be organizing a second meetup in a couple of months and we have already gathered topics we want to talk about!

​Here is the presentation I did gave at this event:

​Here is a picture we captured at the end of the event:

Thank you everyone for coming and I am looking forward to the upcoming meetups.

Cheers

​François Vergès

In 802.11ax communications, the trigger frame is used for multiple purposes. One of them is to allocate ressources for a specific multi-user OFDMA transmission.

In this article, we are going to take a deeper look at some of the interesting fields we will find in this trigger frame. For more details, you can look at section "9.3.1.22 Trigger frame format" of the 802.11ax-D4 IEEE draft.
​

The trigger frame is a broadcast frame and you can use this filter to fidn it in Wireshark: wlan.fc == 0x2400.

It has the following characteristics:

• Type: Control (wlan.fc.type == 1)
• Sub-Type: 2 (wlan.fc.subtype == 2)

​
Here is what you see in the packet capture:

Two information fields are very interesting:

• The Common Info
• The User Info

Let's take a deeper look at what they contain.
​

Here is the structure of the common info field:

Here are some of the interesting sub-fields:

• UL Length: it indicates the length of the expected response frame (filter = wlan.trigger.he.ul_length)
• UL BW (Up Link Bandwidth): it indicates the bandwidth of the transmission (filter = wlan.trigger.he.ul_bw)
  • ​0 means 20MHz
  • 1 means 40MHz
  • 2 means 80MHz
  • 3 means 80+80MHz or 160MHz
• GI and LTF Type: it indicates which guard interval and long training field will be used for the transmission (filter = wlan.trigger.he.gi_and_ltf_type)
  • 0 means 1x HE-LFT + 1.6us GI will be used
  • 1 means 2x HE-LFT + 1.6us GI will be used
  • 3 means 4x HE-LFT + 3.2us GI will be used
• AP TX Power: when the AP sends the trigger frame, it will provide the Tx Power used to transmit the frame (filter = wlan.trigger.he.ap_tx_power)

​
​Here is an example of a common field:

In this example we can see that we will be using a 20MHz wide channel, 2x LFT + 1.6us GI for the multi-user communication. The AP used a combined transmit power of 21dBm to send the trigger frame.
​

The User Info field provides details on each client devices participating in the same upcoming OFDMA transmission.

Here are some of the interesting sub-fields:​

• Association ID: indicates the association ID of the addressed STA (filter = 

wlan.trigger.he.user_info.aid12)

• RU Allocation: indicates the size and location of the ressource unit allocated for the addressed STA (filter = wlan.trigger.he.ru_allocation)
• UL MCS: indicates which MCS is expected the STA to use (filter = wlan.trigger.he.mcs)
• SS Allocation: indicates the number of spatial streams to be used by the addressed STA. You will have to minus 1 to the number. (filter = wlan.trigger.he.ru_number_of_spatial_stream)
• Target RSSI: indicates the the expected RSSI of the PPDU to be sent on the RU (filter = wlan.trigger.he.target_rssi)

​Here is an example of a common field:

In this example, we can see that 2x STA will be sharing the 20MHz channel in 2x 106-tones Ressource Units.
Both client devices are expected to be using MCS 11, 1 spatial streams. And their PPDUs is expected to be received with a RSSI of -30dBm.

Here are a couple of interesting articles you can read to learn more about it:

• UL OFDMA Basic Trigger Frame and Multi-STA-BlockACK From Gjermund Raeen: https://gjermundraaen.com/2019/08/26/ul-ofdma-basic-trigger-frame-and-multi-sta-blockack/​
• LENGTH - The Underestimated Parameter in 802.11 by Gjermund Raeen: https://gjermundraaen.com/2019/11/19/length-the-underestimated-parameter-in-802-11/
• 802.11ax remote packet captures: https://www.semfionetworks.com/blog/80211ax-remote-packet-captures-using-the-jetson-nano
• Clear To Send Podcast Series on 802.11ax: http://cleartosend.net/ax
• Identifying 802.11ax support using Wireshark by Rowell Dionicio: https://rowelldionicio.com/identifying-802-11ax-support-wireshark/​

​​
Thank you for reading!

written by François Vergès

As you know, all data rates are changing with 802.11ax, Hence, the new MCS table you can find here: https://www.semfionetworks.com/blog/mcs-table-updated-with-80211ax-data-rates

In this article, we will see how we can figure out the data rate of a specific 802.11ax data frame.

If you want to know how to capture 802.11ax data frames, refer to this article first: https://www.semfionetworks.com/blog/80211ax-remote-packet-captures-using-the-jetson-nano

The HE RadioTap header provided by the Intel AX card installed on Ubuntu is great and provides a lot of valuable information that we will use to figure out the data rate. 

First, once you have your 802.11ax packet capture in Wireshark, you can filter 802.11ax Data Frames by using the following filter: wlan.fc.type == 2 && (radiotap.he.data_1.ppdu_format == 0x0 || radiotap.he.data_1.ppdu_format == 0x2)

wlan.fc.type == 2 means that we are filtering for 802.11 Data Frames
radiotap.he.data_1.ppdu_format == 0x0 means that we are filtering for HE Single User PPDUs.
radiotap.he.data_1.ppdu_format == 0x2 means that we are filtering for HE Multi User PPDUs.

We simply need to choose the frame we want to analyse. Once you have selected the frame, look for the RadioTap Header in the bottom panel in Wireshark:

In order to be able to find the exact Data Rate used, we need these pieces of information:

• MCS Index
• Guard Interval
• Channel Width or Ressource Unit size
• Number of Spatial Streams

We can find these information in the RadioTap Header.

The MCS Index is located in the "HE Information/HE Data 3" section. In this example, we have a MCS Index of 9: 

​The Guard Interval and the Channel Width/Ressource Unit size are located in the "HE Information/HE Data 5" section. In this example, we have a GI of 1.6us and a channel width of 20MHZ:

The number of spatial streams information is located in the "HE Information/HE Data 6" section. In this example, we are using 1 spatial stream:

Once you have all of the transmission details, you can reference the 802.11ax MCS Table and find out exactly which data rate is used for the communication.

To summarize, here are transmission details what we have for our example:

• PHY: 802.11ax
• MCS Index: 9
• Guard Interval: 1.6us
• Channel Width: 20MHz (OFDMA)
• Number of Spatial Streams: 1

If we reference the MCS Table with this information, we see that the data rate is 108.3Mbps:

As a bonus, you can add the following columns to your Wireshark to display the transmission details we have talked about here:

• radiotap.he.data_3.data_mcs: For the MCS Index
• radiotap.he.data_5.gi: For the Guard Interval
• radiotap.he.data_5.data_bw_ru_allocation: For the Channel Width or RU Allocation
• radiotap.he.data_6.nsts : For the number of Spatial Streams

​Here is what it will look like:

Thank you!

​François Vergès

I was invited to attend and present at the Wi-Fi Design Day in Sydney organized by Ekahau and Dicker Data. I would like to thank Grant, Antony, Darko and the rest of Ekahau's team for organizing such a nice event. We presented at the Opera House, which is such an iconic venue in Sydney!

Stephen Cooper and I talked about Wi-Fi 6 and did a demo showcasing OFDMA spectrum activity and packets.

You can find a copy of my presentation slide deck here: 

Here is a copy of Stephen's presentation. He talked about Wi-Fi 6 Key Features:

Once I have a little more time, I will analyze the packet capture we did during the presentation and present my findings here.

In the meantime, here are a few pictures from the event:

At the end of the presentation, we asked attendees owning a Wi-Fi 6 device to connect to our Wi-Fi 6 network and generate some traffic (speedtest). We looked at the activity on the spectrum analyzer. We also took a packet capture to show them a couple of interesting HE packets.

On my way home, I took some time analyze and get some statistics out of these packets. Here are the results:

Note: No Multi-User data frames were captured

​See you next time Australia!

​Cheers!

In my previous article, I was explaining how you could configure the WLAN Pi to be used in a hotspot mode. Following the article, the configurations have been added to the new WLAN Pi image (starting at 1.7) and it is now part of the default WLAN Pi image (Thanks to Nigel Bowden and Jerry Olla).

​One of the feedback I got is that the Wi-Fi interface is not bridged to the ethernet interface. So, if you are connected to the Wi-Fi network, you will not be able to communicate back to the wired network.

So, in this article, I explain how you can configure the WLAN Pi to allow the Wi-Fi interface to be bridged to the ethernet interface. To make it work, I received huge help from Florent Lassia.

The first thing to do is to enable ip forwarding. To do so, open the /etc/sysctl.conf file and uncomment the following line:

This will enable traffic forwarding between the wlan0 and eth0 interfaces.

Then, we need to modify the DHCP server configurations in order to add the default gateway and DNS server information. To do so, open the /etc/wlanpihotspot/dhcp/dhcpd.conf file and add the following lines:

​Once this is done, you will have to reload the DHCP service on the WLAN pi using the following command:

​Here is the output you should see from running this restart test:

Then, we need to configure the firewall to allow communications between the two interfaces. In order to do so,  you need to modify a line in the /etc/default/ufw file. You will need to set the default forward policy to ACCEPT. It is set to DENY by default.

​Finally, we need to configure a NAT so that all the traffic coming from the Wi-Fi hotspot is natted behind the eth0 IP address. In order to do so, we need to modify the /etc/ufw/before.rules file. At the bottom of the file, after COMMIT, add the following lines:

​Once this is done, you can test your configurations by disabling and re-enabling the firewall. In order to do so, use the following command:

​Here is the output you should get:

Note: the configuration of both the /etc/default/ufw and /etc/ufw/before.rules will not revert back to the default if you go back to the normal mode of the WLAN Pi. You will have to manually re-configure them if you don't want to allow them in the normal mode.​

You can now reboot the WLAN Pi into the hotspot mode using the buttons and it should reboot in the Hotspot mode supporting these bridging configurations. You should be able to connect a client device to the Wi-Fi network and get network connectivity to the LAN if the WLAN Pi is connected to your LAN.

The plan now is to integrate this into the next version of the WLAN Pi image so it could be enabled by default in the Hotspot mode. To be continued…



written by François Vergès

This solution will allow you to perform remote 802.11ax packet capture from your own laptop using the Jetson Nano.
​The benefit of using the Jetson Nano (and the Intel AX200 Wi-Fi card) to perform 802.11ax packet capture is that you get a lot more information in the RadioTap Header you get.
The benefit of doing it remotely is that you never need to directly interact with the Jetson Nano OS (no need for keyboards, screens nor mouses)

To make it work, I received help from a couple of talented guys:

• Jerry Olla
• Gjermund Raaen
• Adrian Granados
• John Kilpatrick

They pretty much found the solutions, I was just the one implementing it ;)

Here is the equipment you need to make it work:

• A Nvidia Jetson Nano
• An Intel AX200 802.11ax Wi-Fi card
• Dual band antennas (Here is the one I use)
• OPTIONAL: A case for the Jetson Nano (Here is the one I use)

Here is what you need to do on the Jetson Nano right after you have loaded the image on the SD card and created your username name:

Then you need to configure Wireshark to do the following:

1. Establish a SSH connection between your laptop and the Jetson Nano
2. Run a tcpdump remotely on the Jetson Nano
3. Stream the packets back to your laptop

​Thankfully for us, Wireshark has a plugin you can install to make it work. It is called SSHdump. You need to make sure that it is checked when you install Wireshark (Under the "Tool" section) (especially when you install Wireshark on Windows).

​When you are ready to perform the packet capture, first you need to SSH into your Jetson Nano and set the Wi-Fi card into monitor mode on the proper channel using the proper channel width:

Then you can click on "Start" and it will start capturing packets and streaming them back to your Wireshark session.

Here are additional resources you can visit to get more details:

• Remote Wireless Capturing with a Jetson Nano from Gjermund Raaen: https://gjermundraaen.com/2019/10/01/remote-wireless-capturing-with-a-jetson-nano/
• Capturing 802.11ax with jetson nano from Gjermund Raaen: https://gjermundraaen.com/2019/09/25/capturing-802-11ax-with-jetson-nano/
• Using the WLAN Pi to scan for networks in WiFi Explorer Pro from Adrian Granados: ​https://www.adriangranados.com/blog/wlanpi-as-a-sensor
• You too can have a sub-$200 802.11ax client from John Kilpatrick: http://wifi.hypergeek.net/you-too-can-have-a-sub-200-11ax-client/
• How to setup Wi-Fi 6 sniffer Wireshark in Ubuntu from Tiger Lee: https://wifilogic.wordpress.com/2019/09/21/how-to-setup-wifi6-sniffer-in-ubuntu/
• The State of Wi-Fi 6 in Practise (WLPC EU Presentation): https://www.cleartosend.net/wp-content/uploads/2019/10/Wi-Fi6_in_the_real_world_wlpc_prague_2019.pdf