When you change the type of external antenna used by an AP in Ekahau, the name of the AP model is not updated to reflect that new external antenna name:

So this simple script aims to update the name of the AP models in order for them to reflect the name of the external antenna actually used. After executing the script, you should see something like this:

Ekahau released a new version (v10.2) last month. The best feature out of this new version (for me at least) is the ability to create personalized tags for AP objects. Each tag can have a key and a value.

​Here is an example:

My good friend Haydn Andrews had the idea to create a script that would auto populate the value of some tags based on the AP properties. This could be used for a lot of AP related properties if you think about it:

• Installation details
• Special bracket needed
• Antenna related information (internet, external, model...)
• PoE budget information
• Service loop required
• ...

In our case we focused on the antenna(s). So we wanted to auto populate the value of three tags that we created:

• antenna-type
• antenna-vendor
• antenna-name

antenna-type would be set to "internal" or "external" depending on the type of antenna used.
antenna-vendor would be set to the antenna vendor (for external antenna only).
antenna-name would be set to the model of antenna (for external antenna only).

That's how the following script was born: https://github.com/francoisverges/semfio-ekahau/blob/master/tag-antenna/tag-antenna.py

The script will create a modified copy of your esx project and leave the original unchanged. However, we recommend running the script against a copy of the original esx project file.

This script will only works if you create the tags within your project before running the script. The easier to do this is to create the three tags on an AP that has external antennas. The three tags to create are: "antenna-name", "antenna-type", and "antenna-vendor".

Feel free to modify it so you can use it with your own tags.

Note: we might update it in the future. So make sure to also check the GitHub repository to see the latest version available: https://github.com/francoisverges/semfio-ekahau

As mentioned previously, the tags (key only) need to be created on the original project file on at least 1 AP object as shown below:

You can then create a copy of your project file (.esx file) and run the script against it:

A modified version of your project file will be created. When you open it, you should see the tags configured with the proper values on all access points:

The flexibility of creating our own tags opens a lot of opportunities for us. Feel free to take this and modify it to your needs.

I have been using the python library called pySerial and wanted to share how I made it work on my end.
​
I have used it to establish a console connection to a Cisco AP in order to perform send the initial set of configurations within a python script and automate the process. I will only talk about using it on macOS as this is what I use. See: Configure a Cisco IOS-XE AP for an APoS Site Survey using Python.

In order for pySerial to work properly, you need to first establish your console connection with the network equipment you are configuring. In my case, I connected it to a Cisco AP.

Use a console cable to connect your computer to the console port of the equipment. In my case, I am using an AirConsole. 

In my case, you can see that the tty I will need is called: /dev/tty.AirConsole-68-raw-serial 

All you have to do to install pySerial is to run this command: python -m pip install pyserial

You can now create a python script. To use the library, you need to import it using the following line:

Then, you will need to create a serial.Serial object that will open the serial connection to your equipment (my AP here). You can do it within a with statement so it can open and close it nicely for you:

You can notice that I need the TTY in order to create that Serial object.
You can also set a timeout of the connection. This is optional and I have set mine to 1sec.
You also notice that I am printing the name of the Serial connection by using the ser.name variable.

In order to send a command, you will have to use this code (in this case we are just sending a return character):

Here are a few things to note:

• The text to be sent needs to be encoded using utf-8
• The '\r' character has to be added to the command in order to simulate the user pressing on Enter (Note: '\n' didn't work for me when interacting with the Cisco AP)
• You will have to use the sleep function to wait for the command to be executed and send you the output back
• The text received will have to be decoded using utf-8

This set of code will have to be executed for every command that you want to send out. So I would recommend creating a function that will do all of this for you. Here is an example:

You can use the wait_time to see how long you need to wait in order to receive all the output from the AP. For instance, you will need to wait longer if you are sending a "show run" vs. sending "conf t".

Here is an example of a script that will connect to an AP (running EWC) and send out the "show ap summary" to discover which APs are joined:

And here is the output when you run the script:

I wanted to play around and see how I could automate the process of preparing a Cisco AP for an APoS site survey. So I decided to try it out on a Catalyst 9120 running IOS-XE. In this article, I will explain how to use the script.

You can find the script on my GitHub: https://github.com/francoisverges/semfio-cisco/tree/master/Setup-APoS-EWC
You can find the documentation of the script here: https://github.com/francoisverges/semfio-cisco/wiki/How-to-use-%22Setup-APoS-EWC%22
​
In order to make this work within a python script, we need to leverage a python library called pyserial which allows us to interact with the AP over a console connection.

This script can be used to configure an Cisco AP for an APoS site survey.
This will only work if the AP is running IOS-XE (Tested with v16.12.02).
This will only work if the AP is running the EWC image with factory configurations.
​This script will rely on you to setup a console connection to the AP in order to work properly.

The set of configurations used to configure the AP can be found here: config-apos-c9120.txt

Note: this script has only been tested on macOS using an AirConsole.

This script require you to have the following modules installed in your Python environment:

• pyserial

If the module is not installed, run the following command to install it: pip install pyserial
I cannot guarantee that this script will work if the AP has already been configured. If it is the case, before running this script, please reset the AP to its factory configuration using this command: wireless ewc-ap factory-reset
Before running the script, make sure that you perform the following:

1. Make sure that the AP is running the EWC code
2. Connect the AP to the network (and provide power via PoE)
3. Wait for the AP to go through its initial booting sequence (this initial boot sequence lasts about 5mins, you should see a solid green LED when it is completed).
4. Connect your console cable to the console port of the AP
5. Connect the other end of the console cable to your computer

All the configurations are located into the config.json file and it is used to configure the following settings:

• Your console connection details:
  • YYT used by the serial connection (Ex: /dev/tty.AirConsole-68-raw-serial)
• Settings related to the Embedded Wireless Controller:
  • Name
  • IP address
  • Netmask
  • Username
  • Password
• Settings related to the SSIDs you want the AP to broadcast:
  • Name of the WLAN profile
  • Name of the SSID
  • PSK
  • Frequency band
• Settings related to the AP we are using:
  • MAC address (can be found at the back of the AP. Make sure to use the "XXXXXXXXXXXX" format)
  • FRA AP (Dual-5GHz compatible AP)
  • Name
  • IP address
  • Netmask
  • Gateway
• Configurations of the 5GHz radio settings:
  • Channel
  • Tx Power (using the Cisco Index value)
  • Channel Width
• Configurations of the 2.4GHz radio settings:
  • Channel
  • Tx Power (using the Cisco Index value)
• Configuration of the FRA radio setting:
  • Channel
  • Tx Power (using the Cisco Index value)
  • Channel Width

​
Here is an example:

Make sure that you set the proper variables in this config.json file before running the script.

​Here is how to install the script to use it on your own machine: 
git clone https://github.com/francoisverges/semfio-cisco.git

Then you can navigate to the script directory: 
​cd semfio-mist/Setup-APoS-EWC

Configure the config.json file with the proper parameters (as defined earlier)
In order to use the script, all you have to do is the following: 
python3 setup-AP0S-EWC.py config.json
Here is what the output will look like if everything goes well:

Note: if you see the following output, juste validate your console connection and re-run the script:

Once the script is done, the AP will reboot. Wait for the reboot process to finish. The AP will then be ready for you to use for your APoS site survey.
​
You can connect it to your favourite PoE battery, wait for it to boot (it takes a while... wait for the LED to be green) and validate that the AP is broadcasting the survey SSID(s):

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