sniffwifi

Just another WordPress.com site

Archive for the ‘iPhone’ Category

A Voice Of Reason On Voice Over WiFi

leave a comment »

Voice over WiFi is scary.  Retries, packet errors (due to lots of Retries) and high latency (usually due to packet errors that happen because of lots of Retries) will murder a WiFi network’s ability to handle Voice and leave your users screaming (not actually screaming) like they were cast in a horror movie (or, at the very least annoyed like a character from Office Space).  But there’s one thing that sometimes scares people, but really shouldn’t: Voice Arbitration.  It’s not going to kill your WiFi voice calls.  In fact, it will almost certainly help.

Arbitration is a process defined in the 802.11 standard.  Every device (client/station and AP) goes through it.

The simplest way I can describe 802.11 Arbitration is like so:

If your AP or station has heard a quiet channel for 37 microseconds (0.000037 seconds), then your AP or station transmits a frame (what most people call a packet, but I call a frame).

If your AP or station has been hearing a busy channel for the past 37 microseconds, then it enters Arbitration. Arbitration is the process by which APs and stations go through a series of procedures in order to avoid devices sending at the same time (and, thus, causing a collision).

The big worry some people have is that Voice will mess up Arbitration.  That it will make it MORE likely that collisions will happen.  The Voice QoS category (as originally defined in the 802.11e amendment) reduces the amount of randomness in Arbitration.  For ordinary (called Best Effort in 802.11e), APs and stations choose a random value between 0 and 15 (on their first try; retries choose from exponentially larger random pools of values).  Voice applications (at least, applications that get tagged as voice by the AP or station) choose values between 0 and 3.  The problem comes when two devices (APs or stations or one of each) choose the same random value during Arbitration.  If that happens, then both devices try to transmit at the same time and most likely a collision occurs.  Two devices choosing the same number between 0 and 15 could happen, but maybe not all that often.  Two devices choosing the same number between 0 and 3 would be far more likely.

The flaw in this thinking is that devices have to be in Arbitration at the EXACT same moment for the 802.11e Voice category to become a problem.  Most likely, they won’t be.

Even though voice applications seem like they’re always running, they’re really not.  Each voice packet only uses about 300 microseconds* (assuming a 39 Mbps data rate — because smartphones don’t support MIMO — and the use of RTS/CTS) or 150 microseconds (if RTS/CTS is not used) of channel time.  And a modern voice application is going to have at most about 90 packets go over the wireless channel per second (combined send and receive).  That’s not a whole lot of channel time.  If we take the example of an iPhone on a typical WLAN — where RTS/CTS is used when the iPhone sends, but not used when the AP sends — that’s only 20,250 total microseconds being used.  20,250 microseconds is 20.25 ms.  Or 0.02025 seconds.  In other words, each phone is only using about 2% of the available channel time when a call is active.

If all of these numbers are too much, here is a visualization of how often a typical voice app is actually using the wireless channel:

The red and blue mean that the channel is occupied, while the empty boxes mean that the channel is unused**.

 Look at all of that open space.  And remember that open space is not the only way that collisions are avoided.  Collisions are avoided if:

-A phone becomes ready to send data while the channel is clear.
-A phone becomes ready to send data while another phone or AP is already sending data (assuming the devices can hear each others’ transmissions).

The only way a collision can occur due to an Arbitration match is if two or more devices begin attempting to send data at the exact same time.  For applications that use as little channel time as voice, that’s just not very likely to happen.

I have found the 802.11e Voice category to not cause problems in high density/congested environments.  In fact, I’ve found it to help.  When voice applications use the 802.11e/WMM Best Effort category instead of the Voice category, an extra 63 microseconds*** gets added to the packet transmission process.  That’s about a 20% jump in used channel time for devices that do use RTS/CTS and a whopping 40% jump for devices that don’t. That means more channel time per packet.  Using more channel time per packet is an actual problem, because it leads to the real reason that collisions tend to happen.  Collisions most often occur because one device is in the middle of sending and another device can’t hear it.  More channel time being used by each packet is most likely going to exacerbate the problem of collisions, not minimize it.

***

*All time calculations include 28 microseconds for a Voice AIFS, 18 microseconds for the Random Backoff (that’s two slot times), 10 microseconds per SIFS, 50 microseconds for non-HT physical layer headers (used by RTS, CTS and Block Ack frames) and 40 microseconds for HT physical layer headers (used by Data frames).

**That little graph has 10,000 boxes, meaning that each box could represent 100 microseconds.  The red dots are a visualization of how much channel time is being used when the iPhone sends (300 microsecs, including RTS/CTS) and the blue dots are a visualizations of the AP sending (since 150 microsecs would mean 1.5 boxes, I just represented half of the AP’s packets with two boxes and half with one box). 

***63 microseconds is calculated by adding an extra 9 microseconds to the AIFS (the Best Effort AIFS is 37 microseconds) and by adding six extra 9 microsecond slot times for the Random Backoff.

***
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

February 24, 2015 at 10:31 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

802.11v: Keep Dreamin’ (in iPhones running iOS 7, at least)

with 3 comments

I’ve seen a lot of 802.11 amendments in my day.  From speed (ac) to security (i) to voice (e), a lot of those amendments have done great things.  But 802.11v isn’t going to be one of them.  One look at an iPhone’s (iOS 7 iPhone, that is) 802.11v capabilities shows that the dream of Wireless Network Management delivering client control is still just that: a dream.
It has long (well, for a dozen years or so) been a desire of WiFi admins to have more control of client/stations.  Control over which AP the client will connect to.  Control over what signal strength (or signal-to-noise ratio [SNR] or error % or BSS density) will trigger client roaming.  Control over which Final Fantasy character they will assume at that weekend’s LAN party.  (I know virtually nothing about video games, so feel free to make dumb jock jokes at yours truly’s expense.)
For about half as long, WiFi admins have had hope for client control on the horizon: 802.11v.  The wireless network management (WNM) amendment was created to (quoting from the 802.11v Abstract), “provide WNM enhancements [blah, blah, blah] to effect a complete and coherent upper layer interface for MANAGING 802.11 DEVICES in wireless networks.”  “Managing 802.11 devices” is the key part there.  The hope was that with 802.11v, a WiFi admin would be able to pause his (or her) game of WoW, slowly turn 15 degrees to the right (so as to avoid rupturing a clavicle from sudden movement) and use his (or her) wireless network management system (WNMS) to manipulate smartphone/tablet/laptop/etc. associations to the various BSSs in his (or h… oh, you get the point) enterprise.  
***
I’ve often been asked the question, “why weren’t 802.11 WLANs designed to allow centralized client control in the first place?” just before a snack sized bag of Doritos gets emptied ass-over-tea-kettle into a network admin’s mouth.  Well, the answer is, “because the AP doesn’t know sh*t.”  APs are mounted above your ceiling (or below your ceiling or, if you’re really doing it right, on your walls).  There ain’t no clients above your ceiling (or below your ceiling or on your walls).  So having an AP that’s above the ceiling (meaning an AP that only really knows RF information about the area above the ceiling) make decisions for a client that’s on a desk or walking down a hallway is poor form.  You want the right RF information so that you (hopefully) get the right decision.  Only the client knows the RF information about its current location.
***
802.11v was supposed to be special because it (optionally) allows APs (or controllers or WNMS) to make decisions about client associations.  802.11v took RF information that the client sends to the AP as part of 802.11k radio resource measurement (RRM) and WiFi information that the client sends as (another optional) part of 802.11v and gives the WLAN infrastructure (APs, controller and WNMS) the ability to paint a picture of the client’s RF environment.  If the AP thinks that the client would be better off on another BSS (which likely would mean another channel), then the AP could use WNM to force the client/station to make that move.
The problem with all of this is that is was never going to happen.  (I use “was” instead of “is” to convey the notion that, not only is it unlikely that infrastructure-based association management will be adopted any time soon, but that it was never prudent to assume that makers of smartphones/tablets/laptops would ever cede control over associations to WLAN infrastructure vendors.)  The authors of 802.11v even ended up making infrastructure control over associations optional because they knew that device vendors wouldn’t adopt WNM otherwise.
Which brings us back to the iOS 7 iPhone.  iOS 7 iPhones do support 802.11v WNM.  You can see it in the Probe Request frames that iPhones send whenever they are unassociated to WiFi.  If you look in the frame body of a Probe Request and scroll down to the Extended Capabilities, you will see WNM information.  It’s tricky, because the WNM information is mixed in with information from other 802.11 amendments.  But if you look at this frame decode (from Wireshark, because I’m lazy and didn’t feel like booting into Windows), you’ll see it:
You see in octet 3 where it shows “Multiple BSSID”?  That’s WNM.  So is “SSID List” in octet 4 and “Geospatial Location” (should’ve been soldered as “America!” in the standard) in octet 2.  
And you know what you see for every single WNM capability seen in that iOS 7 iPhone decode, save one?  0.  “Not supported”.  Apple is giving WiFi admins The Heisman.  They are not allowing your WLAN infrastructure to have any sort of association control.  And what’s more, Apple is not even allowing its precious iOS 7 iPhone to even give the APs/controllers/WNMS any additional information.  (My guess on the reason is battery life, but with Apple who knows?  They’re the kind of company that will foster a pro-gay rights environment for years, champion the cause of gay marriage publicly, and then seemingly go out of their way to keep the fact that their CEO is gay under wraps.  They’re an odd bunch up there in Cupertino.)  In fact, the only part of 802.11v WNM that an iOS 7 iPhone does support is a part that could potentially harm the WLAN infrastructure: directed multicast service (DMS).  (DMS allows client/stations to request than an AP sends multicast traffic as a directed [unicast] frame.  This is probably supported because captive portals featuring web authentication are especially annoying when using Apple devices.  Apparently some guest WiFi services use multicast frames to check whether authenticated clients are still present.  Since many [most? all?] Apple devices sleep through multicast frames if no multicast-based app is running, the end result can be an iPhone/iPad/MacBook user having to re-authenticate to the stinky captive portal dozens of times per day.)
So, at least for now, the dream of centralized management of WiFi clients is dead.  802.11v WNM is approved.  It’s supported.  And all of the parts that would allow network admins to stay at their desks monitoring the fantasy football waiver wire while controlling client associations have been stripped out.  Client/stations continue to control associations and designing the RF environment for your clients’ behavior continues to be the way to get iPhones associated to the right BSS.
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 2, 2014 at 5:54 pm

Posted in 802.11v, iOS 7, iPhone, Wireshark, WNM

iPhones Be Chatty

with 2 comments

You’d think a great company like Apple would care about my privacy BUT NO.

Behold, my iPhone:

You see what’s going on here?  That’s my iPhone there.  Apple_57:8d:89.  (Filtered using wlan.sa == f4:f1:5a:57:8d:89 if you’re curious.)  And look what it’s doing.  IT’S PROBING.  The iPhone of a respected security do-gooder like myself is out there for any hooligan to see.

Do I look like the type of person who wants the world to know that I used my phone at the MGM Signature in Las Vegas?  (Well, maybe.  I could’ve prevented the phone from probing by just tapping on the SSID instead of typing it in.  But typing in SSIDs on iPhones/iPads is a neat trick for keeping stinky captive portal splash pages from coming up over and over again on guest WLANs.)  Or on the VerizonWiFi network at Staples Center?  (Which added a captive portal and lost A TON of guest connections, thus harming overall channel performance for all WiFi users in the arena.)  Why would I want that?  A no-dogooder with a WiFi Pineapple could be all over my iPhone attacking me as we speak.

I’m a nice guy.  I like people around me to be happy.  Do you think I want to be sullying the wireless channel with a bunch of low rate (1 Mbps) frames (of 179 bytes!)?  I’m messing everyone else up!  I want to be the hero, not the villain.

These chatty devices have to go.  I’m going back to my Nokia candy bar phone any minute now.  Any.  Minute.  Now.

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

December 14, 2013 at 1:53 am

iPhone 5 Probes the Right Way, Too

with 2 comments

Quiet when standing still; active when moving.  That is the way that WiFi devices should treat Probe Requests.  Android devices (at least, Android devices that act like yours truly’s Samsung Galaxy Tab 2) probe the right way.  After doing a quick test on the iPhone 5, it appears that Apple has their devices probe based on movement as well.

Apple iOS devices have a terrible reputation in some WiFi circles.  The author has heard complaints about mobility, stickiness, throughput capabilities and just about anything else under the sun.  Heck, just today an article was published decrying the throughput (WHO CARES?) limitations of of the new MacBook Air (not iOS, but still Apple) was viral’d around the web.

To check to see if the iPhone 5 matches the probing behavior of an Andoid device, I associated the iPhone to the office network on channel 36/+1 and started a capture on channel 44/+1.  Then I got up from my chair and started walking around while continuing to use the iPhone.

The results were this:

Notice that the Probe Request frames started coming out immediately when my phone began moving, but then stopped less than one second later.  Most likely what happened was that when I got up from the desk, the iPhone sensed movement and began probing for the next highest 40 MHz channel.  Then the phone probably went from channel to channel as it continued to probe.  All the while the phone continued to stay on channel 36/+1 as much as possible in order to keep communication with the network.
Of course it is hard to draw firm conclusions from a few minutes worth of Wireshark captures, but to these eyes it appears that Apple may be taking steps to get iOS devices in the good graces of WiFi admins and other professionals.  

Written by sniffwifi

June 24, 2013 at 11:13 pm

That Android is Quite the Prober

with 2 comments

No bold type introducing today’s post, as I’m going to keep things short.

I was doing some work last week looking at Android devices (specifically, a Samsung Galaxy Tab 2) and I noticed some very heavy probing behavior.  We were checking out the device’s behavior when it moves from AP to AP, so I set a capture for the target second AP.  I did the test (things went fine, but the WiFi Analyzer app in particular seems to really make Android devices stick to their currently associated BSS) and looked at the capture.

Seeing a ton of Probe Requests from the Tablet was expected.  What wasn’t expected was the Android tablet probing even while associated to the first AP.  Even when the received signal was strong (in the -50 to -63 dBm range), the Android was going off channel to probe and probe excessively.

At this point I’m still trying to figure out if physical motion or an app (or lack thereof) caused the probing.  One thing I am pretty confident in saying already is that updates to Android OS and iOS (the one for iPads and iPhones, not the Cisco one) have really seen the two leaders in mobile operating systems take divergent paths concerning WiFi overhead.  Apple seems to be making their smartphones and tablets probe less, while Android devices are probing just as much, maybe even a little more.

Written by sniffwifi

June 3, 2013 at 10:36 pm

Worthless Capture, Part II (Or, "Why I Need To Buy A MacBook Pro")

with 2 comments

A year ago yours truly wrote about the importance of device location when capturing Wi-Fi frames in a post titled, “Worthless Capture“.  Well, recently another Wi-Fi sniffing bugaboo has become more prevalent: devices that lack the physical capability to capture a  data frames.

This whole problem really stems from 802.11n.  As many people (including the author) found out when the iPad was released in 2010, not all 802.11n devices have the same capabilities.  That is an annoyance to consumers, but it’s downright dangerous to Wi-Fi professionals.  Most Wi-Fi networks require sniffing at some point (for surveying, for event preparation, for troubleshooting, etc.), but most Wi-Fi sniffing devices are incapable of sniffing high rate data frames.

One more time: Most Wi-Fi sniffing devices are incapable of sniffing high rate data frames.

The Linksys WUSB600N, which yours truly uses to sniff with WildPackets OmniPeek?   Only 2 radio chains (a radio chain is a transceiver/antenna pair), so no 3 stream spatial multiplexing (which is required for rates above 300 Mbps) .

The D-Link DWA-160, which is one of the few adapters that works with OmniPeek, Fluke AirMagnet WiFi Analyzer and the Linux version of Wireshark?  Only 2 radio chains.  (Same for the Ubiquiti SR71-USB, which has the same chipset as the DWA-160 and supports external antennas.)

AirPcap NX, which is the only way to get a monitor mode capture with the Windows version of Wireshark?  Also only 2 radio chains.

Basically, if you want to capture high rate data frames with an external Wi-Fi adapter, you’re [excrement] out of luck.  At least most of the time.

What can you use to sniff Wi-Fi frames that use 3 stream spatial multiplexing?

Why, a MacBook Pro (not Air).  The MacBook Pro (like all Mac OS X 10.7 or 10.8 devices) has the Wi-Fi Diagnostics utility that supports monitor mode capture through the built-in Wi-Fi interface.  And the MacBook Pro’s built-in Wi-Fi interface has 3 radio chains.  So the bottom line is that I need to get me a MacBook Pro, otherwise I’ll continue to miss valuable frames when 3 stream data frames go through the air.

It should be noted that a limited number of devices support 450 Mbps Wi-Fi (which is what 3 stream spatial multiplexing maxes out at), so you may not need a 3 stream capture device.  iPhones (and other smartphones), iPads (and other tablets), MacBook Airs, netbooks, eReaders, bar code scanners and point-of-sale terminals all have built-in Wi-Fi adapters with only 1 or 2 radio chains.  The next Sniff WiFi blog post will cover how you can check to see if you actually need to capture using a 3 radio chain adapter.

Written by sniffwifi

April 2, 2013 at 9:24 pm