Getting Data Out of the Windows ‘netsh wlan show interfaces’ Command

-
I recently read a very nice article by Matt Frederick about using a Windows command prompt utility to gain information about what your Windows wireless adapter is up to while connected to a Wi-Fi network ( https://finesine.com/2016/09/17/using-netsh-wlan-show-interfaces-to-monitor-associationroaming/)
In  Matt’s article, he described how he wrapped the ‘netsh’ command into a nice little batch file to run the command regularly, allowing information to be presented in a more dynamic fashion.
I was so impressed with the information provided by the utility, that I decided I’d  try to get the information it provides into a more usable format. In short, I hacked together a Windows Powersell script that runs the ‘netsh’ CLI utility regularly and parses the output data into a CSV format.

By piping the output into a file, you can get a nice CSV file that can be opened in Excel to look at the raw data over a period of time. It’s great for looking at the adapter signal level and BSSID information - it’s easy to spot when your client roams and the approximate signal level at which this takes place.
Fig 1 - You can get output like this...unless you've got good eye-sight, it's better in a CSV :)
A few caveats:
  • I’m not  a coder - this is my first Powershell script
  • This isn’t a robust piece of supported code - it will break easily over time when the output of the ‘netsh’ command changes (refer to the previous bullet)
  • The ‘netsh’ utility natively provides RSSI data as  percentage figure. I’ve converted it to dBm in the script, but the highest dBm figure you’ll ever see is 50dBm ( which is 100% in the ‘netsh’ utility output)...don’t shoot the messenger on that one.
  • This was a bit of fun to do - have fun with it yourself, but don’t get too angry if it doesn't work for you :)
  • Open the script file with Notepad and read ALL of the notes at the top of the file that explain how to use the script.
There are a few challenges getting the script to run without lots of warnings in Powershell - open the script file and read the notes at the top of the file.
By default, the script runs every second, which is nice to roam around and capture regular data. Change the variable ‘$SleepInterval’ at the beginning of the code if you’d like to extend it to a more infrequent interval (2 = 2 secs, 3 = 3 secs etc…)

 Again, have fun with it...oh yes, you can find the script here: https://github.com/wifinigel/win-wlan-data-script

 References:

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would
Read more