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

In this article, I will show you how you can customize your WLAN Pi and make it your own! Feel free to comment and tell me how you guys customize yours.

Here is the video tutorial that explains these customizations.

Creating your own user allows you to have your own password and your own home directory. It is more secure and you are free to modify your profile as much as you want.
Note: I would also recommend you to change the default password for the wlanpi account.

In order to create a new user, you need to ssh into the WLAN. By default, if you connect the WLAN Pi to your laptop via the USB connection, this should establish an Ethernet over USB connection and your laptop should receive an IP address in the 192.168.42.0/24 IP address subnet.

You can now ssh into the WLAN Pi from your laptop using the default username and password:

• Username: wlanpi
• Password: wlanpi

The name of the WLAN Pi is configured under the /etc/hostname file. In order to change the hostname permanently, you will have to modify this file:

1. Open the file using the following command: sudo nano /etc/hostname
2. Modify the hostname to your liking
3. Save and close the /etc/hostname file
4. Reboot the WLAN Pi

When the WLAN Pi comes back online, you should be able to ssh into it and see the new hostname. The new hostname will also appear on the home screen:

One more thing you need to do here. You need to change the hostname used for dns resolutions. If you don't, you will realize that it takes longer for sudo commands to execute. To do so, open the /etc/hosts file and replace "wlanpi" by your new name:

On linux, an alias allows you to create your own command shortcut. For example, instead of typing ls --color=auto, you could create the following alias : alias ls='ls --color=auto'. Then when you type ls, it will execute the full command line.

Everyone has their own set of aliases they like to use. Here I will just share the ones I use. Feel free to use them as well and feel free to create your own.

In order to create your aliases, you need to do the following:

1. ssh back to the WLAN Pi using your new user: ssh francois@192.168.42.1
2. Once connected to the WLAN Pi, modify the .bashrc file using the following command: nano .bashrc
3. Add your aliases at the end of this .bashrc file
4. Save and close the .bashrc file
5. Reload your bash profile using the following command: source .bashrc
6. Validate that your aliases have been applied using the alias command.

Here is the list of my aliases:

You can also customize your prompt to your liking. You can go wild here. I actually like it simple. I like the default prompt. I just changed the colors for fun!

In order to change the look of your prompt, you can do the following:

1. From the WLAN Pi and from your user home directory, open the .bashrc file using the following command: nano .bashrc
2. Inside the .bashrc file, scroll down until you find the PS1 variable. Then replace the value of that PS1 variable with whatever you would want to use.
3. Save and close the .bashrc file
4. Reload your bash profile using the following command: source .bashrc​

Here is the PS1 value that I used for mine:

You can use the following website to customize your prompt to your liking: ​https://www.howtogeek.com/307701/how-to-customize-and-colorize-your-bash-prompt/

When the WLAN Pi, you can see an image appearing on the screen. By default, it is the logo of the Wireless LAN Professionals company.

However you could change it to something else if you want to.

First, you need to retrieve the original image used. It is located on the WLAN Pi at the following location: /home/wlanpi/NanoHatOLED/BakeBit/Software/Python/wlanprologo.png

In order to retrieve this image, I used the scp command from my laptop. This command allows you to copy files from the WLAN Pi to your laptop over an SSH connection. Here is the command I used: 

This will copy the image on your laptop. Then I studied the picture and retrieve the resolution of it: 128 x 64.

Once I knew the resolution, I created my own image using Illustrator. I actually created the two following ones:

Then you need to replace the image that's currently on the WLAN Pi with your new image, freshly created. You won't be able to do it in one shot because you don't have the permission to do so over scp.

So first, you need to transfert the new image back to the WLAN Pi. I transfered mine back to my home directory using the following command: 

Second, you need to ssh back into the WLAN Pi.

​And finally, you need to replace the old image with the new one. I used the following command to do so: sudo cp WLANPi-SemFio-StartUp.png /home/wlanpi/NanoHatOLED/BakeBit/Software/Python/wlanprologo.png

Note: It is very important here that you use the same destination name. The picture name will still be the same as before (wlanprologo.png) but its content will be different. I tried to do it a different way by changing the configuration files of the NanoLED program, but it didn't work properly.

Then, you can reboot your WLAN Pi, you should see the new picture when the WLAN Pi boots.

In order to improve this customization, I would like to create a Python script that automates all of these tasks. I will then be able to run the script every time I update my WLAN Pi to a newer image and I will be able to retrieve my customizations.

If you manage multiple WLAN Pi, you could also create a Python script that you could run on multiple WLAN Pi to speed up their configurations and customizations.

Please share how you like to customize yours!

Thank you for reading!


​
Written by François Vergès

This is a very simple article just explaining how you can connect to a Cisco WLC (aireos) using a python script.

You could use this as a first step in developing more advanced Python scripts to monitor or configure your Cisco Wireless Lan Controllers.

I am still learning Python so this might not be the only and easiest way to do it!

We will assume that you have already Python installed on your computer. I would also advise you to use virtual environment when developing Python scripts on your computer.

Here is the tutorial I have followed in order to setup my laptop (macOS) for Python programming: ​https://developer.cisco.com/learning/lab/dev-mac/step/1

Here are the program and libraries we will be using here:

• Python 3.7
• netmiko

Here is how I setup a virtual environment for Python 3.7 on my  laptop:

Here is how I installed the netmiko library within this new virtual environment:

Here is the Python code you will need to in order to connect via SSH to a Cisco WLC. Obviously you need to gather this information first:

• IP address of the WLC
  
• Username allowed to SSH into the WLC
  
• Password associated with that user 

In this example, we are using the object called ConnectHandler from the netmiko library to establish an SSH connection to the WLC (192.168.20.2).

​Once connected, we are sending the command "show ap summary" and we are displaying the output of this command.

Connecting to the Cisco WLC could be the first step in a more complex script. Therefore, I have done the following in order to ease the process:

1. Created a configuration file where I keep my WLC details (IP address, username and passwords)
2. Created a script that I called ssh_wlc.py that defines function that will establish the connection based on the WLC configuration file

I then re-use my script as a "library" whenever I work on a script and I need to connect to a Cisco WLC.

Note: Python 3.5+ is required here since we are using PEP 484 type hints.

Here is what my configuration file looks like (I used xml so it is easier to parse):

Here is what my ssh_wlc.py script looks like:

As I continue to learn more about Python, I will continue to share it with you guys on the blog.

If you know other alternatives to do the same thing, please feel free to add a comment.

Thank you!


​written by François Vergès