sniffwifi

Just another WordPress.com site

Archive for the ‘AirMagnet WiFi Analyzer’ Category

…And If You Buy That Survey, I’ve Got Another Survey To Sell You

with 8 comments

I recently got into a little tiff on Twitter.  In part it was an argument about blogging and reaching a broad audience, but mostly it was about site surveys.  Site surveys are hot right now, but I find that surveyors often overlook an important aspect of WiFi: different devices act differently.

Conventional wisdom for WiFi site surveys is to get some site survey software, upload a floorplan and start a-surveyin’.  First predictive (letting the software estimate where coverage will go), then active (temporarily mounting access points in the locations chosen in the predictive survey and testing connectivity) and finally verification (walking the site after APs have been installed).

The problem with all three types of surveys (predictive, active and verification) is that they are done with site survey software.  Site survey software is great for selling APs or pacifying execs, but it usually requires using a specific adapter.  So every time you verify connectivity or see a certain received signal strength (RSSI), you’re not testing the network for users.  You’re testing the network for your survey adapter.  Usually, that means that your site survey software is giving you deceptive information.

I did a little test to illustrate the problem of different adapters acting differently.  I went out on my back patio and brought several WiFi devices to see RSSI.

First, I used AirMagnet WiFi Analyzer to view the RSSI of the Proxim 8494 (which is the same thing as the NIC-300 if you use Ekahau Site Survey).

The screenshot above shows an RSSI (circled in red) of -66 dBm, which is solid.  The graph above the RSSI shows that it fluctuated, but always stayed above -70 dBm.
I then viewed the RSSI of three devices.
My MacBook Air (802.11n – 2 streams) showed -71 dBm in the screen shot below, for the most part stayed BELOW -70 dBm with some moments above.
My iPhone 5 (not 5s or 5c), which has supports single stream 802.11n, was recorded at -72 dBm (seen below) and went as low as -79 dBm.  The iPhone did have moments above -70 dBm, but was consistently lower than the MacBook Air’s RSSI.
That makes things tough.  Most WiFi networks are going to support a heck of a lot more iPhones and MacBook Airs than USB adapters.  If I were to rely on that Proxim 8494/Ekahau NIC-300 adapter while surveying, I would be off by a few decibels.  In some cases a three to five dB difference may not matter, but in some cases it could create what I call “Dead Zones”, where the survey shows coverage but users get unacceptable WiFi access.
(There was some good news.  My Samsung Galaxy Tab 2 (below) showed a signal strength more or less on par with the RSSI of the USB adapter.  I took a screenshot at -67 dBm using the WiFi Analyzer app from farproc.)
So, reading RSSI in site survey software is a problem.  Great.  Now what do we do about it?
One direction I’ve been taking is to focus more on using actual devices and less on site survey software.  That means more focus on the “active” survey and less on the “verification”.  The verification survey is necessary if you have a manager or executive who likes looking at colors over a floorplan, but I’ve found myself avoiding that whenever possible.  I think it’s better to spend more time testing service to temporarily mounted APs using real devices and less time selling the traditional walk-around survey.

***
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

ben at sniffwifi dot com

Twitter: @Ben_SniffWiFi

Advertisements

Written by sniffwifi

July 3, 2014 at 10:48 pm

Device Retry% in Fluke AirMagnet WiFi Analyzer (Video!)

with 3 comments

So I’m milling around Twitter one afternoon when someone told me that Fluke AirMagnet WiFi Analyzer was overwhelming.  Well, it is if you don’t know what to look for.  And since I’m in the midst of developing an online class about WiFi sniffing, I decided to whip up a shabby-looking 10 minute video that might help those who feel overwhelmed.


If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

Thank you.

Written by sniffwifi

March 28, 2014 at 12:10 am

Now It’s AirMagnet’s Turn to Show Us QoS

with one comment

In my last (real) post, I detailed how I used WildPackets OmniPeek to solve an iPhone 5 QoS problem.  But what about AirMagnet WiFi Analyzer?  I am a fan of both of those fine WiFi sniffers, so I figure it’s a good idea to show you how QoS can be analyzed with Fluke Networks’ signature WiFi protocol analyzer.

WildPackets OmniPeek is more of a hardcore protocol analyzer than AirMagnet WiFi Analyzer is.  If you’re going to be doing the type of sniffing I detailed in the last blog post, you will have an easier go of it with WildPackets’ product.  But AirMagnet is popular and both tools are expensive.  So if you happen to be a gal (or guy) who needs to troubleshoot WiFi voice or video and you have AirMagnet, this brief tutorial should help.

To begin analyzing QoS, one must first capture on the VoFi devices channel.  In my case I associated my iPhone 5 to a network with the SSID of “R&T”.  Then I looked at the Start screen in AirMagnet:

The “R&T” access point was on channel 44.

Once you know the channel that your VoFi device is on, then next step is to start capturing and viewing frames in the Decodes screen of AirMagnet.  It is at this point that I should note that the wise Keith Parsons once told me, “If you’re looking at the decodes in AirMagnet, then you’re in the wrong place.”  And that is true, usually.  But in the specific case of needing to find out which WMM QoS categories are being used by your VoIP app, then the Decodes screen is the right place to be.

I navigated to the Decodes screen in order to view captured frames.  I selected channel 44 as my capture channel and then I applied a capture filter for my iPhone, as shown here:

Once I had my filtered capture running, my step was to generate some voice traffic so that I could test QoS.  I used Truphone, which is a WiFi-based calling app.

After capturing VoFi frames, WMM QoS categories can be seen by opening a data frame and viewing the 802.11 header.  The 802.11 header has a field called “QoS Control”, and inside that field the TID (traffic identifier) will indicate which WMM access category is being used.  For Truphone, the category was Best Effort:

AirMagnet makes it a little bit more difficult to see the WWM QoS Category than other WiFi sniffers do.  For one thing in AirMagnet a capture must be stopped before frame decodes may be viewed.  For another the TID subfield is not summarized.  When the TID value is zero that means Best Effort, which is simple to remember.  The other categories are a bit more odd.  Voice is 5 or 6.  Video is 3 or 4.  Background is 1 or 2.  Seeing the raw bits of the TID field like in the AirMagnet capture above is fine for people who have memorized those numbers.  WildPackets OmniPeek and Wireshark decipher the number and tell you the category, which makes things easier for people who spend less time focusing on WiFi.  Like in this example below, it would’ve been nice if AirMagnet made it clearer that the frame I was looking at it Voice instead of forcing me to remember that 0110 in binary is 6:

In summation, the process for figuring out whether WiFi-based QoS will help your applications is rather straightforward.  Capture on the channel.  Run the app.  View the headers.  And if you do that it can really help you predict whether your VoFi apps will work well on a crowded channel.

Written by sniffwifi

November 21, 2013 at 12:39 am