Tuesday, January 15, 2019

Comparing Ekahau Sidekick to other tools

I’m going to start this post with saying that the idea for this post came from the rssicompared.com website where I have posted some data.  This was more of “me, out in the field”, but this time I had a little extra time, a pad of paper, and some help from @WiFi_Princesa (and WHY hasn’t she been on twitter lately??)


We heard reports of bad Wi-Fi coverage for the Cisco 8821 series phones.  We both thought, “horsefeathers”.  Not on my watch!


We went onsite, and sat where the red dot is indicated below.  On the table were a few Wi-Fi clients/tools:


My Ekahau Sidekick

Netscout G2

Cisco 8821

Samsung S7 Edge


We had heard of “lousy Wi-Fi coverage” in the room with the red dot is located.  In order to prove it is not the network, we have to prove it is something else.  We made a rudimentary table of signal strength (since that is what was reported) on the devices we had with us:


Device:                                Cisco 8821          Netscout G2       Sidekick Samsung Galaxy S7 Edge


Access Point 04  -64                        -68                        -57                        -57


Access Point 05  -70                        -75                        -65                        -72


Access Point 03  -78                        -75                        -66                        -76


First of all, we learned that signal strength was not the problem, since we designed it for -67 dBm, and we met the requirement’s signal strength of -64 dBm.  Things are not always as they seem, since the strongest AP was #4, when you might expect one of the other two would be stronger.


The second thing we learned is that the farther we were from an access point, the more the results varied.


We also learned the Ekahau Sidekick “heard” anywhere from 5 to 10 dB better than the other devices.


Since all we can do is average out the set of clients, we are going to say that the Ekahau Sidekick can hear about 8dB better than some other popular devices.


Our next quest is going to see how an AP can see the other access points, since we need to know how the Cisco access points can hear each other.


Friday, October 19, 2018

Comparing Sidekick, Proxim, Comfast and Edimax adapters in Ekahau ESS

My last blogpost compared my Sidekick to my Proxim adapter.  I did this because I used to use a Proxim, and now I use a Sidekick for WLAN surveys.  I have colleagues that use the Edimax and Comfast adapters, so I went out and purchased a few so I could compare.  I did this because a year or so ago, I was comparing my Proxim survey to a colleague’s Comfast survey.  We both did the same building, but at different times, and the results were way off.  They differed so much I though the other machine had a bad WLAN adapter. 
So here we go again, comparing the four adapters listed above.  This is of the same facility as last time, however a different part of the building that came online recently.  Same requirements for the WLAN, same guy doing all four surveys.  Same machine, same walking speed, same ballcap and same worn out tennis shoes.  This time I am going to show -60 dBm so I can fit it on the graphic.  There is no other reason for this, so please don’t go using -60 dBm as a survey requirement because you saw it here.  I normally look at -67 dBm for voice surveys if you were wondering.  This is 5 GHz, of course.   I’m also not going to compare every AP, because there’s no point. 
Now I’m going to get right to the point.  Here they are:
Sidekick -60 dBm
Here is my Proxim’s adapter at -60 dBm.  Very Similar to the Sidekick.  I expected this, since I did a validation a few weeks ago and highlight that in my blogpost.
Now the Comfast CF-912AC USB network adapter @ -60 dBm:
Last but not least, the Edimax AC1200 at -60 dBm:
My only comment is, “hey, nice ears, Edimax.  I would say that the Edimax adapter saw the APs slightly louder than everyone else.  Not by much, though.  Just for kicks, I have knocked 5 decibels off the Edimax view above and it sort of looks like the others.  Maybe that is because the Edimax has the little plastic antenna that folds out.  I’m not going to pry mine apart to find out if it is empty plastic or if it actually has antennas in there.
I have been slowly adding some WLAN adapters to rssicompared.com, and I have high hopes of adding all my adapters to that site so we can all benefit.  I am also creating my own little spreadsheet that will become a blogpost that compares the network adapters I find in my daily life.

Saturday, October 6, 2018

Comparing my Proxim 8494 to my Sidekick

This blogpost is simple.  I used to use a Proxim 8494 for surveys, now I use my Sidekick.  All I wanted to know if how my SK and Proxim 8494 compared.
I recently did a 5 GHz validation survey of a new healthcare facility WLAN with requirements of Cisco Voice and Aeroscout RTLS – only this time I walked it twice.  Once with Sidekick, once with the Proxim.  Here are the results: (I will put Proxim on left, SK on right).  I’m using Primary 5 Ghz signal strength at -65 dBm for your viewing pleasure.  Why only 5 GHz?  Ask Devin Akin…
Here's AP number one.
I’m not going to show every AP.  There’s no point, since my goal is to see how they compare, so I know what I am looking at.
I will now skip to another part of the building:
And now for another area.  Keep in mind… These surveys were done on the same day, same time (one before the other) with the same machine.  Only thing different was the survey adapter.  Same human, wearing the same ballcap and same tennis shoes.
Now that I have my results, I can clearly see that my Proxim and my Sidekick are somewhat similar in the way they receive the signals from the WLANs they are surveying/validating.
I know that many of you are like me and might have several Proxim 8494 adapters, and when surveying with them you may have seen different results.  When I discovered this, I started to use only one Proxim for validations – not two or three in a USB hub configuration, since I didn’t “trust” my multiple adapter configuration.  But that’s just me.
Again.  The point of this blogpost is simple. I just wanted to see how my “survey adapter” I have been using for way too many years compares to my Sidekick.  I am not trying to say “only use one Proxim for validations”, or “STOP - go buy a Sidekick immediately” (I’m sure Ekahau would like that, however).  What we all hope for is that all Sidekicks are baselined/benchmarked/created-equal.  What I mean by that is that if my Sidekick saw the WLAN at -65 dBm in a certain area, that your Sidekick will see the same thing.  I think we all know that our Proxim 8494 adapters are not exactly created equally.  I am in no way trying to say anything negative about the Proxim adapter.  I am trying to compare apples to apples, however, and I feel that apples from the same orchard/tree/harvest might taste the same.  I have a half dozen Proxim adapters, and they all seem to see the world differently – much like all the humans I know.  And you know who you are.
I don’t have two Sidekicks.  If I did, you can bet I would perform this same “experiment” with my SK and anyone that wanted to send me their SK for a few days.  Better put your name on it, though.
Another thing to mention:  You can always “see” how different adapters see the same exact signal – just go do rssicompared.com and take a look for yourself.  I know that all APs and clients are not created equally, and they all seem to see the world differently.  Better yet, add some data of your own!
My best advice:  Know your APs, know your WAN requirements, know your client adapters, know your applications.
There will be a Rev2 of this post.  The building has another section, and I am going to survey that three times - once with SK, once with my other Proxim, and a third time with another adapter that I have not chosen yet.  When complete, I will compare those results as well.

Wednesday, August 29, 2018

How to test your RADIUS configuration on the Cisco 5508 controller without having APs and clients.

How to test your RADIUS configuration on the Cisco 5508 controller without having APs and clients.

Authentication problems are pretty common when configuring the WLAN controller to authenticate users on a WLAN against a RADIUS server.

When configuring the WLAN controller, you have to create the WLAN itself on the controller, and then create the RADIUS Authentication and Accounting configurations as well.  This is where most of the problems lie.  If the RADIUS keys do not match, the users will not be able to get on the WLAN.

Create the WLAN according to your requirements:


Create the RADIUS Authentication and Accounting configurations:


Go back to the WLAN and add/select the AAA servers you just created:

With the WLAN completely configured to your requirements (meaning, configure the other requirements on the other tabs for the WLAN) it is time to test.  One way would be to use an AP and a client and try to join the WLAN.  However, if you are remote, and configuring the WLANs for future deployments, not being onsite presents a challenge when testing the RADIUS configuration on the WLAN Controller.

This document assumes you are comfortable with command line access into the WLAN Controller. 

We are going to use the “test aaa radius” command to test the scenario mentioned in the paragraph above.  We are going to use a fictitious username and password of “juser” & “mypassword”.  Since we just created the WLAN, we know it is WLAN ID #5, and there is no AP Group, so we will use “default-group”.  We just created the RADIUS server configuration, and its server index is #1.

Here is the syntax of the command:

Test aaa radius username juser password mypassword wlan-id 5 apgroup default-group server-index 1

Next, you have to issue a command, “test aaa show radius” to see if everything is working correctly: (your session will tell you the command to issue, as seen here:


Here’s a successful authentication test output:

(Cisco Controller) >test aaa show radius

Radius Test Request

  Wlan-id........................................ 5

  ApGroup Name................................... default-group

  Server Index................................... 1

Radius Test Response

Radius Server         Retry Status

-------------         ----- ------            1   Success

Authentication Response:

  Result Code: Success


Here’s an unsuccessful authentication test output:

(Cisco Controller) >test aaa show radius

Radius Test Request

  Wlan-id........................................ 5

  ApGroup Name................................... default-group

  Server Index................................... 1

Radius Test Response

Radius Server         Retry Status

-------------         ----- ------            1   Success

Authentication Response:

  Result Code: Authentication failed (this is wrong username/password)


Here’s an unsuccessful authentication test output because controller cannot reach server:

(Cisco Controller) >test aaa show radius

Radius Test Request

  Wlan-id........................................ 5

  ApGroup Name................................... default-group

  Server Index................................... 1

Radius Test Response

Radius Server         Retry Status

-------------         ----- ------            6   No response received from server (this is self-explanatory)

Authentication Response:

  Result Code: No response received from server (this is self-explanatory)


Here’s how to test RADIUS Fallback:

Make sure it is configured:

Make sure both authentication servers are listed in the WLAN profile

Then go back to where we were in testing:

(Cisco Controller) >test aaa show radius

Radius Test Request

  Wlan-id........................................ 5

  ApGroup Name................................... default-group

  Server Index................................... 1

Radius Test Response

Radius Server         Retry Status

-------------         ----- ------            6   No response received from server            1   Success

Authentication Response:

  Result Code: Success







Tuesday, July 24, 2018

How to remedy the non-digitally signed driver issue with AirMagnet and Windows 10

If you’re a WLAN Engineer, you likely have a lot of Wireless tools in your arsenal.  At the last wireless conference I went to, I took the CWAP course, and we installed Omnipeek on our laptops.  Many of us had an issue where we had to configure our laptops to be able to install a driver that was not digitally signed.


One of my tools is AirMagnet Wi-Fi Analyzer.  I have been upgrading my toolbox and decided to install the software on my new machine, which is a Dell with Windows 10 on it.  I downloaded the same old multi-adapter kit drivers that I had done in the past, but this time the Proxim 8494 adapter was not seen when I launched it.  I looked in the Device Manager and found the dreaded exclamation point.


I remembered back to the CWAP class, and that we had a similar issue.  I tried the “fix” that we had done in class to no avail.  I tried everything that Google told me to do.  Still nothing.  Admitting defeat, I called Netscout support and explained my issue.


It turns out there is a digitally signed driver that will make this problem go away!  The gal on the other end of the conversation pointed out to me that there is a digitally signed driver on the Downloads page.  It doesn’t say “digitally signed” anywhere on the description, but it does state Windows 10.  I downloaded and installed it and it fixed the issue.   The digitally flavored driver to download is the one my red arrow is pointing to.


Saturday, July 21, 2018

Outdoor GPS site survey - using Ekahau ESS/GPS & Venvolt MK1


Most WLAN Engineers I know don’t have to do outdoor APoS surveys very often, however when you need to, this post might come in handy. 

The last time we did an outdoor survey, we used a lightweight Cisco 1532i series access point, a small PoE+ switch, a Cisco 2504 WLAN controller and a fairly large UPS to power it all.  We learned that an AC inverter plugged into a 12v power outlet in a vehicle just didn’t work for us and would not charge the UPS when driving from point A to point B.  We had to look for power outlets and drag long extension cords around – which might get damaged if people drive over them. 

This time, we changed it up a bit.  Our task was to test a Cisco 1532e series access point with an external directional antenna.  For this, we purchased the new Ventev Venvolt MK1 power supply that can supply PoE+ (802.3af & 802.3at) power to an autonomous AP that requires 802.3at power – for hours on a single charge.  We loaded the autonomous code on to the access point and then configured it like you would an autonomous AP during an APoS survey. 

We used the same old survey cart and telescoping pole that we always use, mounted everything like you would expect it to see on an outdoor wall or pole, and plugged it into the new Venvolt MK1.  A few minutes later, the AP was online and ready to go.  Here’s what the rig looked like:


 We configured our Ekahau ESS site survey software to do an outdoor survey.  There are a few HowTo’s floating around on how to do it.  I must admit, we spent the previous day getting ESS to work with the GPS adapter.  We had to download drivers, etcetera, and go through all the motions to get it working.  It wasn’t simply plugging in the GPS receiver and running out the door.  That said, spend the time to get all of that working first.  I used a BU-353 GPS receiver, if you are wondering.  Set an hour or two aside the day before (or longer) and get that working.  Do not wait until you are in the parking lot with your AP up high on a pole and then decide to embark on that task.  You might need access to the Internet to get the drivers, etc.  Familiarize yourself with how to use ESS with a GPS outdoors – figure out how to start and stop the survey, etc.  Practice with it at home if you live in a quiet neighborhood, or in a park, or somewhere else where someone won’t call the police on you.

When you are setting up your project, you need three locations in a triangle on your “floor plan” before you start surveying.  We were indoors when creating the project, and we figured out that when looking at maps.google.com, it was giving us the coordinates in Decimal degrees, and ESS wanted Degrees, minutes and seconds (DMS). 

We searched around and found this website to convert decimal degrees to DMS: https://www.latlong.net/lat-long-dms.html  I believe if you install Google Earth on your laptop, it will give you the requirements you need in the format ESS wants.  We didn’t want to go that route – just our preference. 

We also used the same website where we got the “floor plan” to measure the distance between two corner parking spaces, and then used that measurement in our project.  Worked beautifully. 

I cannot stress enough to set everything up before you go out on-site to do your survey!

With our project ready to go in ESS this is what we looked like: 

 Our first “driveabout” was to see how much energy would be behind the panel antenna.  We aimed the antenna to the south, put the GPS and Wi-Fi adapter on the roof of the car and started driving around.  As we expected, we had some RF propagation behind the panel antenna, seen below: 

Why is this important?  Keep in mind all the channels that we use/don’t use, and if this antenna is on a pole, it is susceptible to interference from that direction.  Since our application will be pole mounted, we mounted it on a pole to see what might happen in the installed environment.  If we were going to install this antenna on a brick wall, we would have parked our survey rig up against a brick wall and walked the other side.

For our next driveabout, we moved the survey rig to an area that had a row of small trees between the rows of parking.  I think it is rather obvious where the trees are:

The point of this is to see how far the 5 GHz signal will propagate outside, when impeded by a number of small trees.  That distance is about 100 feet.  The fewer the trees, the farther the signal goes.  We have to keep in mind that these trees are going to likely grow in the future, so if we were covering this parking lot, we would have to plan for that.  One thing to note – having trees is not necessarily a bad thing.  Having attenuation outdoors keep your cell sizes smaller – all part of a carefully crafted RF plan.

Our third test spot was closer to the road that is more like a long hallway in a building with less attenuation.  As you can see from the graphic below, the signal traveled almost twice as far in that spot:

From this testing, we learned a few things:

  • We now have a good feeling of how the antenna’s RF propagates.
  • Height and antenna down-tilt affects the size and shape of the cell.
  • Trees attenuate RF which affects the cell size.
  • We measured the 2.4 GHz cell size, which was larger, but won’t be using it for the deployment and will be turned off.
  • Outdoor site surveys attract Police cars.
  • *Keep in mind the transmit power and channel selections may increase/decrease the cell size. 

To sum it all up – a little planning at the beginning of an outdoor deployment may save a lot of time and money in the long run, since installing outdoor Wi-Fi gear can be expensive.







Monday, July 9, 2018

A Healthcare WLAN build from start to finish - and why it should be built as designed

In March of 2015, I did a blogpost “5GHz WLAN Site Survey AP power settings - What you want, don't want, and don't care about.”  In this post, our goal was to find out the best minimum and maximum transmit power setting of a particular access point’s 5 GHz radio.  That post can be found here: http://justdowifi.blogspot.com/2015/03/5ghz-wlan-site-survey-ap-power-settings_7.html

We needed to determine the Wi-Fi coverage area of the access point at a particular transmit power that was going to be deployed in a building on a large hospital campus.  This coverage area data was used to model the WLAN using Ekahau’s Site Survey software.  In the blog post from 2015, we determined that the min/max transmit power would be 8 dBm and 14 dBm, respectively, and would provide the following -67 dBm cell coverage:

When modeling a WLAN with Ekahau’s ESS software, we need to choose a wall type.  In order to properly determine wall type/attenuation value, you need to measure the attenuation of the walls/doors/floors, etc.  This technique is taught in the Ekahau ECSE class and has probably been explained in a few WLAN Engineer blogs.  In the past I used a battery powered access point, but now I use an Odroid for that job.  More on that Odroid can be found here: http://www.morefrag.com/odroid/Odroid%20WLPC%20Excercises%20%5BFinal%5D.pdf  Other WLAN Designers/Engineers are using a new and improved single board computer, which can be found here: http://www.wlanpi.com/
Basically, you need a signal source – in my case, the battery operated Odroid and something to read the signal strength on the other side of the wall.  My wall measuring kit contains an Odroid single board computer, a Leica laser measuring tool to get accurate distances, a Netscout Aircheck G2 to read the signal strength, and of course, a clipboard with the floor plans on them for me to write on.  I bought the zipper case, the foam, etcetera, and made my own carrying case with places for everything to go so that I would notice when I forgot to put something back in its place.  I find it is the easiest way to not leave some of my tools behind.  Here’s my kit:

Use the signal source and signal strength meter to measure the RF attenuation in free space (about 20-25 feet apart) and then with a wall between the source and meter.  Same goes when measuring floor attenuation – bring the meter to the room beneath you and read the signal strength.  You can do the math to figure out how much attenuation is in the wall/floor and that information can be used when modeling and designing your WLAN.  This is outlined below.

Place your signal source in an office and walk through the open door into the hallway and measure the signal with your meter.  For this example, let’s say your signal meter reads -56 dBm.  Now move your signal source to the other side of the room, away from the door, and walk back to the hallway, closing the door behind you.  While standing in the hallway, opposite from the signal source, read your meter.  If your meter now reads -59 dBm, you know that your wall has 3 decibels of attenuation.  You may find a small tripod works well for consistency when positioning your RF source.  The image shamelessly boosted from one of Devin Akin’s presentations.

You will need to annotate the wall attenuation values however you see fit.  This information will be used later, so standardize how you do it so you’ll remember what your symbols mean.  When you feel you know the attenuation value of the different kinds of walls, you can then use the data to model your WLAN design.  If you have CAD files, you can import them for your project and you can assign attenuation values of the walls at that time and always modify as needed afterwards.

We looked at the construction of the facility and determined the wall types – most all of the walls were 3 dB since this was a wing with patient rooms and construction was similar throughout.

In healthcare, wall measurements can be tricky.  Most every hospital I have designed Wi-Fi for has been under some sort of renovation at that time.  Imaging departments, Operating rooms and other areas must not be overlooked when measuring wall types – assuming the entire hospital has 3 dB walls could be a costly mistake.  Many office areas have lead in the walls because the area used to be an imaging department.  During the renovation, the lead was never removed.  MRI areas are usually enclosed with a metal mesh, and block RF from going through.

Since many hospitals use location based WLANs to triangulate assets, we typically design the facility to meet those requirements.  This usually means we start at perimeter of the facility and work our way in when designing the wireless network.  We typically design to a given signal strength (RSSI) for the RTLS solution, combined with capacity calculations from our voice and data requirements.

Many large organizations with thousands of access points never statically employ the power and channel plan that was is in the original WLAN design.  The design often turns out to be “this is what your WLAN could look like if you follow these directions,” however most organizations simply choose a channel width, channel lineup and min/max transmit power and let RRM take care of the channel plan.  This is the case with this design as well.
This WLAN was designed almost three years ago, and is now built and up and running.  The power and channel plan is being controlled by RRM, and the WLAN Validation survey was completed recently with Ekahau ESS and the Sidekick.

Here is an overview of the Network Issues from our 5 GHz, 20 MHz channel width WLAN design.  The purple areas are the areas highlighting the areas where we have overlapping channels.  Notice that most of the channel overlapping occurs in hallways or other open areas where the RF is not attenuated as much.

Here is the same Network Issues view from within ESS of the Validation Survey.  The Validation Survey is a WLAN survey of what is actually built and up and running.

You may be thinking, “hey, wait a minute! Why are they different?”  The answer is “what is deployed is not actually what was designed.”  If we take the original design and modify the channel plan to match what RRM is doing, look what happens:

Look familiar?  Of course it does!  We have now modified our WLAN design to mimic what RRM is going, and they show similar results.  This is actually good news!  This means that we got it right.  From this point on, we are going to compare our design (using RRM’s channel plan) to the validation survey to see if they are similar.  If so, we know we did our design correctly.

Let’s look at a few other views, comparing what was design to what is actually up and running.
The graphic on the left is from the APoS survey, the one on the right is from the Validation Survey.  They match – now that’s good news!

This design had a requirement for what is known as “Secondary Coverage.”  Secondary coverage is a typical requirement for VoWi-Fi handsets so they can roam properly throughout a facility.

Here is our designed Secondary Coverage:

Here is our Validation Survey’s Secondary Coverage: (They’re pretty close).

For those of you who have access to Cisco Prime Infrastructure, you may have heard WLAN Engineers state that we want to see “mostly 3’s and 4’s” on our Cisco Prime maps.  If you are curious how much power is on each access point, see my previous post on Cisco 3802i series power levels.  The post with the power levels can be found here: http://justdowifi.blogspot.com/2018/07/cisco-3802i-series-power-levels.html

Now that we have shown that our implemented wireless network matches our modified designed network by matching the design to the actual implementation, let’s see how a nicely designed network can be implemented incorrectly.  Keep in mind this is the same design we started out with.  Here’s the design at 11 dBm transmit power, UNII bands 1,2 &3, with 20 MHz channels.

First off, we’ll make it better by including more channels in the lineup.  We will incorporate some of the U-NII-1, 2a, 2c&3 channels.  Notice the channel overlap literally disappears!  The purple color indicates channel overlap.

Using the same channel lineup as the original design, I am going to “virtually” login to the WLAN controller and turn on 40 MHz channels.  Look what happens!

Keep in mind that channel overlap is not a good thing.  Reconfiguring a WLAN without actually going into the original design and running some “what-if’s” could negatively affect your wireless network.

Another thing to mention is the channel overlap doesn’t always come from your access points.  If you are in a metropolitan area with older buildings, your 40 MHz and 80 MHz channels might interfere with your neighbors across the alley and the floors above and below you, depending on the age/construction of the building.  If your access points are interfering with your neighbors that likely means their access points are interfering with yours as well. Using a 20 MHz channel plan in a dense environment may actually increase your throughput!