Just another site

Archive for July 2014

I Guess Apple Wireless Routers Don’t Like… Anything?

with one comment

I’ve seen a lot of inexplicable stuff in my day.  Landlords advertising Free WiFi and then telling you to use the neighbor’s.  Twitter praise from people whose employer I had just criticized in a blog post.  USC journeyman quarterback Mark Sanchez picked fifth in the entire NFL Draft.  But when I saw that my sturdy Apple Airport Extreme (single radio, dual band, two-stream 802.11n) wireless router was tagging all of my apps as Background traffic, I just couldn’t explain it.

For those who are unfamiliar with WiFi quality of service (QoS), a quick primer:

WiFi Multimedia (WMM) certified devices use QoS protocols from the 802.11e amendment.  Primarily, that means classifying APPLICATIONS (not networks, not devices) as either Voice, Video, Best Effort or Background.  What happens when a device classifies an application as Voice (highest priority)?  Whenever that device is ready to send a frame (sometimes called a packet) from that Voice application the device has to wait less time before sending.  What does less time get you?  It gets you a better chance of being the next frame to use whatever channel you are on.

The bottom line is that you want voice applications to be Voice.  If an app is Voice, there is a better chance it will work if your AP’s channel gets congested.

What you don’t want is for your voice applications to be Background.  Background is the lowest priority level.  Apps that are Background have to wait the longest possible amount of time before the device sends their frames.  That is bad.  It makes those apps vulnerable to shabbiness when your AP is on a congested channel.

So, what is my sturdy Apple Airport Extreme doing?  It is classifying EVERYTHING as Background.  TruPhone (my preferred voice app when traveling internationally), Facetime, the WWE Network and MLB At Bat were all sent using Background by my Airport Extreme.  My iPod Touch (rapidly becoming my favorite WiFi surveying device) wasn’t using Background for those apps.  It was using Best Effort.  In fact, it even used Video for some packets when I ran the Dish Anywhere app.  But look at this Wireshark capture from when I ran Facetime (sorry, I was too lazy to plug in my OmniWiFi and run WildPackets OmniPeek on my virtual machine):

That’s Background, Apple!  For a voice app!  THAT YOU MADE!  Whyyyyyyyyy?!?

Maybe it doesn’t matter that much.  Maybe it’s just my router.  (It is old enough to be single-radio, you know.)  Or maybe Apple has some cool new protocol going.  Maybe Apple’s WiFi team found out that if you have a clear channel, that the extra quiet time between frames for Background devices (seven slot times during the arbitration interframe space [AIFS] instead of three slot times for Best Effort or two for Voice & Video) results in fewer collisions.  Yes!  That’s it!  Apple figured out something none of us knew and is saving us from collisions without us even knowing it!  (Actually, no.  I switched to a crowded channel and the Airport Extreme kept on churning out Background frames for Facetime.)

The truth is I don’t know why my wireless router was classifying my voice and video apps as Background.  I know the Cisco AP in the office wasn’t.  See:

The thing that really bugs me is that I recommend the Apple Airport Extreme to people all the time.  As consumer-grade wireless routers go, I find it to be the best.  It doesn’t block wireless printing (a problem that a lot of Arris wireless modems seem to have), it doesn’t require random power cycles (a problem that every other wireless router ever seems to have) and it has good range.  I like it.
I have another Airport Extreme, a more modern one, that I’ll test when I’m back home in Los Angeles.  For now, I will just remain perplexed.  Why does Apple (at least for traffic coming from their wireless router) want my Facetime to have low priority?  I don’t get it.
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


Written by sniffwifi

July 31, 2014 at 11:50 pm

…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

Written by sniffwifi

July 3, 2014 at 10:48 pm