Just another site

Archive for the ‘QoS’ Category

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

QoS the Packets of iPad (a poem)

leave a comment »

QoS the packets of iPadand all through the air 
not a station was Probing, not even a hair
When suddenly on to my Wireshark screen
Appeared Video, Voice and Background, it seemed
“But alas”, I exclaimed, as I looked at the MACs
This is only one tablet, not a bushel or stack
To the standard I looked, to decipher the meaning
And to you, dear reader, I offer this gleaning

The standard in question is dot11e

and the goal of its authors was to keep the air free
from clutter like YouTube and Facebook or Twitter
that might cause your voice conference to lag and/or jitter
But remember, dear sniffers, we’re still talking WiFi
A world where each access point, smartphone and MiFi
makes its own way to the channel or not
deciding on rates, QoS and the lot

So take heed if your WiFI must work for those apps
that users just love but treat admins like saps
a smartphone may say, “this packet is Voice”
but the AP may reply, “Best Effort; no choice”
And thus if your tool is a management GUI
You could end up wondering why WiFi is pooey
But a sniffer will show — be it angst or delight —
Whether your gear plays nice or girds for a fight


(iPhone: ‘This is a Video app.”)

 (AP: “You’ll get Best Effort and like it.”)

If you like my blog, you can support it by shopping through my Amazon link.  Same Amazon store and prices, but I get a kickback.  Thank you.

Written by sniffwifi

January 23, 2014 at 9:26 pm

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