Wednesday, July 22, 2020

Why doesn't 802.11a data show up when surveying with Ekahau Pro and an iPad?

Why doesn't my 802.11a data show up when surveying with Ekahau Pro and an iPad?

For over a year now, I have been plagued by an issue when troubleshooting/upgrading WLANs.  The issue is simple - when I step into a site with little to no documentation, I start off with a Validation Survey to see what the environment looks like - and it helps to find APs that might be lurking behind filing cabinets, on desks, on book shelves or sitting on top of ceiling tiles - or my favorite, which is hanging on the wall like a clock.  When I find them, I always ask my colleague what time it is.  The reply is always, "it's time to get that AP mounted properly!".  Please don't put ceiling mount APs where they don't belong!

Back to the issue regarding the validation survey and the "Mystery of the Missing 802.11a 5GHz data".  The first time it happened, I thought I had done something wrong.  Surely I had misconfigured something on the iPad somewhere.  I walked a site that had both 1131s and 3502s on the ceilings and I noticed a pretty green map on the 3502i series side of the house.  I kept walking, not looking at the data as I thought it was collecting fine.  When I returned to the office, I noticed when reviewing the file on my desktop that the 5GHz 802.11a appeared to be missing where the 1131s were.  I asked around and nobody had a great answer as to why this is happening.  After all, Ekahau Pro is a WLAN survey platform and there are a bazillion customers using it and nobody has seen my issue.  I was convinced it was something I was doing.

This is what the floor looks like from the documentation/monitoring side of the deployment:

It is difficult to see, but that is the floor with the APs on it, showing the APs with the channel and power levels on them.  They are Cisco 1131s (they have internal antennas) and are dual band access points with 802.11a and 802.11g.  They are not 802.11n or greater.  The graphic show both radios online, and their power and channel selection.

A few weeks ago, I went to a site I needed to schedule and did a quick test run with a laptop and Sidekick as I knew the site had 1131s on the ceiling.  I walked the site with my laptop and Sidekick for five minutes and verified I had both bands in a very small area, and then made an appointment to walk the facility with the building supervisor.

I changed one thing the following week when I walked it.  I saved the project to Ekahau Cloud, and walked it with my iPad and Sidekick.  When I saw the results below, I started to wonder if the problem was with the Ekahau Cloud/iPad/Sidekick combination.  Here's what the first floor validation looks like with that combination of survey and only that floor's APs selected: (three APs in the middle were upgraded to 802.11n and they show up)

As you can see above, there is no 802.11a data at all from the 802.11a radios.

Next, I walked the floor with Ekahau/Laptop/Sidekick (project saved on SK) combination.  See graphic below.  Here's what the first floor validation looks like with that combination of survey and only that floor's APs selected.  Since we all know battery life is important (and we had already walked the entire second floor with this combination, we decided to only do this half.  As you can see, the 5 GHz 802.11a data shows up when we use the Ekahau/Laptop/Sidekick combination.

Next, I walked the floor with Ekahau/iPad/Sidekick (project saved on SK) combination.  See graphic below.  Here's what the first floor validation looks like with that combination of survey and only that floor's APs selected.  As you can see, the 5 GHz 802.11a data does not show up when we use the Ekahau/iPad/Sidekick combination.

Finally, I turned to a trusted old friend, AirMagnet Survey Pro.  I used the Edimax AC1750 adpater and walked the site yet again.  As you can see from the graphic below, the 5GHz spectrum is correctly mapped out for me.

My conclusion is that the iPad will not gather 5GHz (802.11a) data from an 802.11a radio.  I do not mean 802.11a/n or 802.11a/n/ac/ax radio.  I think I have ruled out the issue as an Ekahau Cloud issue, as I saved the projects to the Sidekick for this test.  It looks as if the iPad is the culprit.

I looked at some older surveys (pre-iPad) and verified that 802.11a data displays properly.

I feel that being able to see 802.11a data is important.  Even if you don't have older protocol APs in your network, your neighbor might have them and when you survey, you won't pick them up if you use the iPad.  I'm just going to have to use a laptop and Sidekick.  I'm also wondering if I can get a refund for the iPad/cloud, as it is not useful to me anymore.

Sunday, December 1, 2019

How to reset your Ekahau visualizations (and why you might want to check them)

How to reset your Ekahau visualizations (and why you might want to check them)

Eighteen months ago I was asked to give a ballpark number of access points for a small campus of buildings consisting of multiple floor each.  After a quick glance at the floor plans I knew I had to do some sort of predictive design in order to get a ballpark number, and luckily some produced some CAD files.

I created the project and went to site verify the walls were accurately placed, marked off where I could not place access points, and went back to my desk and created the model so I could give the project manager a ballpark estimate.

Eighteen months later, I was asked to do the same thing since the first project had not taken flight and this time the project manager stated they needed a voice implementation.  Probably a good thing the first project didn’t get any traction since that design would not have worked for VoWi-Fi.

When I opened the project up, I noticed something was off.  Note: if you are following along, I am using version 10.1
First of all, my signal strength is set to Primary.  Yes, the word “Primary” is not there, but it is implied. (to the best of my knowledge, anyway)  Notice the bottom middle AP does not have any heat map around it?  Neither does the AP in the middle.  That was red flag #1.

I then turned my visualization to the 2.4 GHz, which I usually do not pay that much attention to since I usually concentrate on 5 GHz WLAN designs.  Same thing – the middle AP doesn’t have any “heat” on the heat map, and I didn’t turn any radios off yet. 

Then I selected “Both”, and I now knew something was wrong.  If you look at the bottom middle AP in both visualizations above, there is no green above the bottom row middle AP, yet there is in the “Both” visualization.  How can that be?  If “Both” is both 2.4 GHz and 5GHz painted on the monitor at the same time, how can I have green where there is none on either of the last two visualizations?

When seeing this, I started questioning myself.  I started asking myself if I fully understood what exactly these views meant.  I asked multiple people who were all Ekahau Masters if their visualizations were accurate, and they said they were.  But they were not looking at my project file. I honestly started doubting myself about my knowledge of these visualizations, and then came to the conclusion that my knowledge was accurate and there was either something wrong with my project file or the software.  Then I started checking other views within the software – specifically the “Secondary Signal Strength” view.

Under this view, I selected two APs and the 2.5 GHz and came up with something that I thought I might see in real life:

Then I selected 5 GHz and saw this view:

Then I did the unthinkable.  I clicked on “Both”.  I rarely, if ever, use this view:

I thought to myself – WHAT?  How can that be?  That is supposed to be where these two APs overlap each other with both bands on – basically, a sum of the two graphics above it.  This made absolutely no sense to me!  During all of this, I opened two support tickets with Ekahau, but after a day of not hearing from anyone, I figured they were closed due to a holiday that I am unaware of.

Then I selected one AP, kept it on Secondary, and selected the 2.4 GHz visualization: (looks good)

Next I selected 5 GHz and didn’t see anything there either. Again, looks good.

Then I selected Both, under Secondary, and the single AP:

That is not what I expected to see.  Why?  Because from the Primary & Selected & 2.4 GHz, I don’t see anything on the heat map:

Let’s look at the 5 GHz: (again, nothing)

Therefore, how could the Secondary Signal Strength & Selected & Both with the single AP display anything?

Now I knew something wasn’t working properly.  I went back to Secondary Signal Strength & Selected & Both and looked at it again:

I thought to myself, “The coverage area is too large”  and then I was reminded that when Secondary is selected in conjunction with “Both” and only one AP is being selected, that “Both” will display the area where both 2.4 GHz and 5 GHz reside from that one AP.

That is not what I expected to see because, in theory, that should be the same view as Signal Strength & Selected AP & Both, and that same AP selected.  And then I remembered I was on Secondary and it was displaying out to -70.  If we slide the Primary out to -70 and compare, they should, in theory, be the same.

They look pretty close too me. 

I have now come to the conclusion something is messed up with either my project or the software.  I asked several awesome Wi-Fi Engineers (thank you, you  know who you are) and I was informed that we can “reset” the views within Ekahau Pro.  I figured “what else have I got to lose?”.

In order to do this, go to “View” in the bar across the top.  Scroll all the way to the bottom, and look for View Settings, then Restore View Settings to Original Defaults:

I clicked through the “Are you sure” type of messages and 15 seconds later, my visualizations are all fixed.  Here’s a re-graph of one of the first heat maps in this post, and that is what I expected to see the first time.

One thing is for sure – I am going to keep a closer eye on my visualizations.  I’m not exactly how the visualizations got “broken”, but they did, and I am thinking about doing the reset on every file as a preventive maintenance.  And now you know how to fix it.

Tuesday, November 19, 2019

Using the Service Port on Cisco 3504 WLC

When setting up new Cisco WLAN controllers, I find it easier to set one up, get it working properly and then copy the configuration off of it and put it on another WLC and change what needs to be changed in order for it to become a backup controller.  You know – the IP addresses need to change, hostname, and then set up the mobility configuration.  Everything else as well – I’m sure I am forgetting to mention something.


My most recent pair of WLCs threw a curve ball.  I set up the first 3504 WLC via the CLI while on the bench with a very basic config, then copied my base config file to it via TFTP.  Everything went well, and the system rebooted.  After relogging in via CLI, I tested the Service Port’s IP config with a patch cable to my ethernet port on my laptop.  I tried to browse to it, and nothing happened.


I pinged the WLC, and the service port responded.  I then SSH’d into the service port and it worked perfectly.  But no web browsing!

I went home and came back to work the next day, and I could browse to the WLC.  Nothing changed.  I thought that was a bit strange.


After getting the WLC all setup like I wanted, I copied the controller’s config off the WLC via TFTP and began to set up the backup controller’s configuration.  Everything was successful, and I changed what needed to be changed via CLI, saved the config and rebooted it.  When it came up, there was no browsing – same as the first WLC.  I looked at the system time, and it was set properly, however it was not connected to the internet and the NTP configuration was not in use.


After asking a few friends and googling around, I started trying different things one by one.  I found one post where someone had to regenerate the webauth certificate (for something else), and I also found in that same post there was a command to regenerate the webadmin certificate as well.


I ran the “config certificate generate webadmin” command and executed quickly, however it did not appear to do anything.  I saved the config and typed “reset system” and it rebooted.  When it came back up, I could browse to the WLC.



I honestly have absolutely no idea why this worked, but it did.  I do not know why the first WLC worked the next day, but not the first day when I configured it.  If my friend Sam Clement’s theory was correct, it was the NTP setting – and I suspect it had not timed out.  My timeout was set to one day, and I do not know if more than 24 hours had passed when I checked the first controller again and it magically worked.


I hope this helps someone, since when I searched, I found no references to anyone else having this same issue.





Thursday, October 17, 2019

One of the coolest features of the netAlly EtherScope nXG is being able to charge it via PoE.  We’ve all been there – using your favorite tool of choice, and you notice you are low on battery – usually at an inopportune time in most cases. 

Those days are in the rearview mirror with the netAlly EtherScope nXG.  The EtherScope nXG has the ability to be charged with the charging cable that comes with the unit, but also via PoE. 

In this quick tutorial, I am going to show you how to configure it to charge via a class 4 PoE port.  You’ll know when you have it configured properly when you see the charging “lightning bolt” in the battery icon in the status bar in the upper right hand side of unit, as seen below:

In the upper left of the EtherScope nXG, you see the AutoTest icon.  You’ll need to press that button (you have likely done this many times by the time you read this) after plugging in the Ethernet port into a Class 4 PoE switch – just like the photo above.  That will run the AutoTest.  Here are my results below.  Note: I plugged into a not-so-smart switch port, so that is why we see “Nearest Switch Not Found”.

In the upper left, you will see three horizontal lines that are commonly referred to as the “hamburger”.   Go ahead and press that and the following screen will appear.  Look for General Settings down near the bottom and tap that with your finger.  

Near the bottom, you will see “Charge battery via PoE”.  It will likely not be enabled if you have determined that your EtherScope nXG is not charging via PoE.  Simply tap that with your finger and enable it, then press the “back” triangle in the lower left, under the word “Management”.

 Now that you have pressed the “back” arrow button, you should be at the screen below:

You will now configure the unit to expect Class 4 PoE power.  Press the Settings icon (gear) next to the word START.  The following screen appears:

Tap the Wired Profile card somewhere in the middle of the card – in that empty space.  That will bring you to the settings in the Wired Profile as seen below:

As you can see, the PoE Test is set to Class 4, which will allow the EtherScope nXG to be charged via PoE.  I will go through the motions of setting it to Class 4 in case the unit is set to something else – which will likely not allow the unit to be charged via PoE.  From this point on, we will assume the unit showed PoE Test Class 1.

Press the PoE Test card and it will bring you to the PoE test page as shown below.  The PoE Test should be enabled, and needs to be set to Class 4 on the Powered Device Class card.  Since we are assuming it is set to Class 1, press the Powered Device Class card.

Once the Powered Device Class card has been pressed, the Powered Device Class screen should pop up, allowing the selection of Class 4 as shown below:

Select Class 4 and press OK.  Tap the “back” triangle in the lower left four times and it should bring you to the main screen.  If the EtherScope nXG is plugged into PoE Class 4 power, you should now see the unit charging – and now you’re ready to enjoy this awesome feature!

Tuesday, September 3, 2019

False Expectations and Confusion with 802.11ax

There is a lot of confusion and false expectations regarding 802.11ax flavored Wi-Fi these days.  Articles that compare 802.11ax to switches sets a dangerous president and leads to confusion in the marketplace as to what 802.11ax is and what it can do.

Take this article as an example:


"With 802.11ax, MU-MIMO has been enhanced to support uplink traffic, from the client to the AP, and will support up to eight clients at a time (802.11ac allowed for eight, but no one implemented more than four). This doubles the number of devices to which an AP can talk, and because traffic is supported in both directions, clients can transmit simultaneously back to the AP, similar to how an eight-port switch would work on a wired network."

Here is where the confusion lies:  A client cannot transmit simultaneously back to the AP while receiving a frame from the AP - meaning, full duplex.  That is not in any 802.11ax draft amendment.  If this was possible, this is still not similar to how an eight port switch works.  Ethernet switching allows clients to send traffic on the wire whenever they want because the connection to the network is not a shared medium.  Wi-Fi is an unbounded, shared medium in unlicensed frequency band.


"Wider channels can support even more sub-channels. An 80 MHz wide channel can support up to 37 clients at a time. Like MU-MIMO, OFDMA supports downlink traffic, from the AP to the clients, and uplink traffic, from the clients to the AP. If MU-MIMO is a high speed 8-port switch, then OFDMA is a lower speed 37 port switch."


Here is where the confusion lies:  A client cannot transmit simultaneously back to the AP while receiving a frame from the AP - meaning, full duplex.  That is not in any 802.11ax draft amendment.  If this was possible, this is still not similar to how a thirty seven port switch works.  Ethernet switching allows clients to send traffic on the wire whenever they want because the connection to the network is not a shared medium.  Wi-Fi is an unbounded, shared medium in unlicensed frequency band.  Also, an 80 MHz channel is simply the aggregation of four 20 MHz channels into one channel.   If there are twenty 20 MHz channels and five 80 MHz channels, they are using the same spectrum.  Currently, date frames are transmitted consecutively using the entire channel. For example, if a client is connected to a 20 MHz wide channel and sends data, the entire channel is taken up and then the AP and clients take turns, one at a time, sending data on the channel.  This will continue until all of the legacy 20 MHz client devices (802.11a, 802.11n, 802.11ac) are removed from the network.  This includes the WLAN's access points and client devices, and also neighboring WLANs that are within earshot of the 802.11ax network.  It is not uncommon to do a survey of an existing building and see 700+ neighboring access points.  This number does not include the client devices on those 700+ access points.


"This has led to designs with more lower-bandwidth channels to reduce interference. 40 MHz-wide channels are the norm in office deployments, with 20 MHz wide channels used in high density offices or in environments where there are fewer channels available because of noisy RF neighborhoods.  BSS coloring allows the network to assign a “color” tag to a channel and reduce the threshold for interference.  Network performance is improved because APs on the same channel can be closer together and still transmit at the same time as long as they are different colors. Because we can have fewer channels, it may also be possible for organizations to use wider channels, such as 80Mhz channels in some or all of their network." 


Here is where the confusion lies:  The previous paragraph states "This has led to designs with more lower-bandwidth channels to reduce interference. 40 MHz-wide channels are the norm in office deployments, with 20 MHz wide channels used in high density offices or in environments where there are fewer channels available because of noisy RF neighborhoods."  Enterprise Wi-Fi networks should usually be set to 20 MHz channel plans because of the density of access points due to the data/voice/RTLS/higher density design and the noisy RF neighborhoods of the facilities.  80 Mhz channels are not usually used in Enterprise environments, therefore that does not apply.

"If MU-MIMO and OFDMA make the wireless network behave more like a switched environment, then BSS coloring adds switching capacity to the network."


There is a lot of confusion regarding 802.11ax - especially with this subject.  MU-MIMO and OFDMA does not make the wireless network behave like a switched environment, therefore that statement is not accurate.  Switching uses CSMA/CD, (carrier sense multiple access with collision detection) and Wi-Fi uses CSMA/CA, which is carrier sense multiple access with collision avoidance.  The two are massively different than each other - CD can sense a collision, which usually does not happen now that we plug hosts into switches and the collision domain exists between the host and the switch.  Collision Avoidance is still the same.  The medium is still in a shared spectrum with all those cordless phones, video cameras neighboring networks and everything else I have forgotten to mention.  None of those things exist in the copper cabling between a host and a switch with CSMA/CD.  There is no way to "detect" a collision with Collision Avoidance - if the station did not receive an acknowledgement for the unicast packet it transmitted, it will retransmit the packet, assuming the receiver did not receive it.


"With MU-MIMO, an AP can behave like a high speed, 600 Mbps per client 8 port switch, great for large file transfers and high-performance clients. OFDMA allows an AP to behave like a lower speed, ~25 Mbps per client 37 port switch, good for normal network use and voice and video streaming.  An AP can switch back and forth between these two modes every transmit cycle as the needs of the clients change. We don’t have a dedicated connection for each device like you would in a wired network, but we are able to adjust the amount of network capacity allocated to each device depending on need, which is something wired networking can’t do. Although we don’t have a full-duplex switch, we effectively have time-division duplexing that emulates full duplex over shared/half-duplex mediums. In the end, we gain a lot of the benefits of switching and wireless and 802.11ax is likely to be the point where we think of Wi-Fi less like an old bridged network and more like a high-speed modern switched network."


Even more confusion:  An AP cannot behave like a high speed, 600 Mbps per client 8 port switch.  Switches use CSMA/CD, and 802.11ax will use CSMA/CA.  A switch is full duplex - meaning simultaneous transmit and receive to a client, as long as the port negotiates properly.  802.11ax is not full duplex.  Switches commonly use gigabit speeds on every host port, and 802.11ax does not equal an eight port (or 37 port) 1000 Mbps full duplex (no collision domain) Ethernet switch.  We do not "gain a lot of the benefits of switching" with 802.11ax.  We do not have collision detection, we still share the frequency/channel with all the other wireless devices on that frequency, and we do not have full duplex (simultaneous) transmit and receive to a client.




Wednesday, August 21, 2019

NetAlly's AirCheck G2 gets a facelift with version 4.0 firmware


NetAlly's (formerly NetScout) AirCheck G2 gets a facelift with version 4.0 firmware


We learned at Mobility Field Day 4 that NetAlly has been working on version 4.0 of the AirCheck G2 firmware, so here is a quick post on how I upgraded mine.  I decided to take the “offline” approach because sometimes you don’t have an Internet connection to get the job done.  I know that seems hard to believe, but I once worked at a place where no USB anything, no phones, no cameras, no nothing was allowed through the checkpoint.


So here goes:


                    Download the AirCheck G2 Manager v3.1.485 software from the support page at (, and install it on a PC. (I installed on Windows without issue)

                    Note: When you get to the website, scroll down until you see this, and select the Aircheck G2.



                    When AirCheck G2 is selected, these files will show up:  I downloaded all of them into the same folder.




                    For whatever reason, I could not download the MAC Prefix File, so I scraped it into a Notepad and saved it as a .txt file.


                    Download AirCheck G2 v4.0 firmware (, and save it also.  I put mine in the same folder.  The firmware is the ACFX file.





                    Launch the newly installed AirCheck G2 Manager v3.1.485.


                    Attach your AirCheck G2 unit to your computer using the micro USB cable.


                    In AirCheck G2 Manager v3.1.485 go to the Device Info screen, select the “Update AirCheck G2 Firmware…” button.




                    Follow the prompts to upgrade your unit to the v4.0 firmware. The unit reboots and takes several minutes, so do not do this step if you don’t have time to do it.


                    Next, I uploaded the vendor OUI text file I created.  This was extremely simple.






Now I am going to see if everything “added” to the firmware works as described:


1. 802.11ax Visibility: I have an 802.11ax client on the network and I will see if the AirCheck G2 sees it: (and it does)

How did I take that screenshot from my AirCheck G2?  This is on page 104 of the manual: (I didn’t know how to do it either)

I used the AirCheck G2 Manager to get the screenshot since I am using the non-link-live way of upgrading my AirCheck G2 today.  I simply transferred them to my PC – it was very painless to accomplish.



                    Identify 802.11ax Networks – Sadly, I do not have an 802.11ax access point to verify this – however I could clearly see my 802.11ax laptop was identified.


2. Combined Utilization View: This option allows the combination of 802.11 utilization and non-802.11 utilization into a single total utilization graph that will include 802.11a/b/g/n/ac/ax traffic and non-802.11 traffic.

            Here is how to get there to make the change: (I made the change back and forth but did not have an environment to see any results)



3. iPerf Test Results Uploaded to Link-Live:


In order to get to the iPerf test function, you first need to connect the G2 to an AP or Network, run a test and when complete, look at the bottom of the screen for “Tests”.


If you use the NetAlly Test accessory, it should show up in the list.  If you don’t know what I am referring to, look at this link:

I use the WLANPi iPerf server (available here: and I had to enter in the IP address of my device.  I ran the iPerf test just fine, and it did upload to Link-Live, however it did not end up in my inbox like all the other tests I ran.  I am not sure if this is because I am using the wlanpi instead of the NetAlly device.


Overall, the new version 4.0 does what it says it does.  I would like to see the iPerf end up in my inbox automagically in a future release, or possibly some documentation on how to make it happen.




Monday, July 15, 2019

My Ekahau Sidekick offsets


Ekahau users that use the Sidekick have probably discovered that the Sidekick “hears” better than other devices?  How much better, you ask?


Since I do a lot of validation surveys, I decided to do a comparison between four devices.  The 5 GHz Vocera “communicator” badge that is deployed quite a bit in Healthcare, the “Netscout” AirCheck G2 (in parenthesis because I heard that Netscout doesn’t own that product anymore though the name is still on the box), my handy dandy Samsung Galaxy S7 Edge (that just so happens to be the platform used by a company that deploys Google Glasses), and my trusty Sidekick.


My main concern was “what is my Vocera offset” for doing surveys to determine if the WLAN is voice quality.  So, we took two Vocera badges and put them side by side, and during our testing, averaged the two into one measurement.  I must say this was easy, since the Vocera badges usually agreed with each other within one dB.


We tried not to skew the results in any way.  We didn’t look at previous results during the testing.  We didn’t look at other results and compare while testing.  We simply walked through a medical office building and randomly stopped in areas and took readings.  This was intentional, as we didn’t want to add “intelligence” into the equation.  We even took measurements in the basement, where coverage was minimal.  When complete, we added them up and divided by the number of readings.  Very simple.


Sometimes we throw out “highs and lows”, and average the rest.


When using the data we gathered, not tossing out the highs and lows, our offsets came out like this:


Vocera                 -11.66 db

AirCheck G2        -13.44 dB

Galaxy S7 Edge   -13.66 dB


When using the data we gathered, tossing out one high and one low, our offsets came out like this:


Vocera                 -12.00 db

AirCheck G2        -13.14 dB

Galaxy S7 Edge   -13.28 dB


Moving forward, I feel as though a 12 dB offset can be used in my environment when looking at the WLAN surveys with Vocera communicators in mind.


Actual readings walking a floor of a medical office building:


Ch:         Vocera  G2          S7           Sidekick


44           -46         -49         -55         -40


44           -77         -75         -76         -64


64           -61         -56         -56         -46


56           -69         -74         -76         -55


52           -68         -69         -74         -59


36           -73         -74         -75         -62


161        -68         -66         -60         -53


36           -70         -79         -76         -59


48           -78         -84         -90         -67        



dB Difference between each device and SK


Ch:         Vocera  G2          S7           Sidekick (original dB reading)


44           6             9             15           -40


44           13           11           12           -64


64           15           10           10           -46


56           14           19           11           -55


52           9             10           15           -59


36           11           12           13           -62


161        15           13           7             -53


36           11           20           17           -59


48           11           17           23           -67