Just another site

Archive for January 2014

A Choice of Filters

with 5 comments

People who do WLAN analysis agree that filtering is a part of sniffing WiFi frames/packets.  More information can be extracted from captures when the focus is on one AP or station or protocol (or a combination of same).  Where people disagree is on which type of filtering is best: capture filters or display filters?  Yours truly is a capture filter man, and some iPhone analysis was a reminder why.

Filtering 802.11 captures is covered pretty well in the CWAP Study Guide (of which I am a co-author).  A capture filter extracts frames before they are captured.  The only frames captured are the ones that match the filter.  A display filter extracts frames after they are captured.  Every frame is captured.  Then the filter is applied so that only frames matching the filter are shown in the protocol analyzer.  To use the example of a filter on my iPhone, if a capture filter were used then all of the frames from all of the other stations on my iPhone’s channel would be lost.  Using a display filter, on the other hand, would mean that everything is captured.  Nothing is lost.  The filter for my iPhone would be applied after the capture has been done, thus allowing frames from other stations to be analyzed later.
The CWAP Study Guide takes a neutral position on WiFi capture filters, but the CWAP course written by Marcus Burton is friendlier to display filters.  The rationale make sense on the surface: with a display filter nothing is lost.  If an iPhone is being analyzed and the iPhone’s frames appear to betray a congestion problem, the display filter can be removed and frames from other stations or APs can be examined.  If a capture filter is used, then that moment of congestion may have been lost.  Those uncaptured frames can never be examined.
There is a down side to using display filters, especially in a congested area: the lack of real-time analysis.  It can be tremendously valuable to be able to watching frames as they are being captured.  If you know what WiFi should look like, then you may be able to identify cases where the WiFi is having problems.  (That’s how I fingered the APs as the culprit when investigating that iPhone VoIP problem that I blogged about a while back.  I watched the frames show up in OmniPeek in real time and saw a stream of Retrys.)  
In general, the best way to filter will depend on your level of expertise.  If you are relative new to sniffing WiFi, then it’s probably best to use display filters.  You probably won’t know what to look for in real time, so it will be best to keep all captured frames.  Once you become an expert, then switching to capture filters is usually better.  The ability to correlate real world, real time behavior (What app is running now?  Is the tablet moving now?  Is the user actively using her device now?) with that scrolling trace of captured frames/packets is often valuable in identifying what is really going on.

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 30, 2014 at 6:09 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

Mighty iPhone Power Ranges II (With iPads)

with one comment

About a year and a half ago, yours truly wrote about WiFi transmit power levels in iPhones.  Things have changed since then.  And possibly the biggest change (to iPhones, at least) is how aggressive iPhones are in modifying transmit power levels.  

In the “Mighty iPhone Power Ranges” blog post, I wrote about the value of setting AP transmit power levels to approximately the same level as client/station device power levels.  Over the past year or so, more and more client/station devices have started using adaptive power levels.  A typical implementation would force a device to lower its transmit power when receiving a strong signal from the AP and raise its transmit power when the AP’s signal is weak.

The unanswered question is, “just how vast are these ranges of transmit power levels?”  Can a smartphone or tablet go as low as half power?  10% power?  0.0001% power?  Those differences could have a major effect on a WLAN infrastructure’s ability to handle a variety of devices.

I decided to do a quick, unscientific test of device transmit power levels while on a non WiFi-equipped plane.  I sat the device directly adjacent to my 2012 MacBook Air (which has a 2-stream 802.11a/b/g/n WiFi radio) running in monitor mode.  Then I let the device send Probe Request frames looking for nearby WiFi networks.  I used the received signal strength in those Probe Request messages to see if my WiFi devices were changing power levels.

The first device I checked was a 3rd generation iPad, which has 1 stream 802.11a/b/g/n radio.  I let my iPad send Probe Requests for while.  Initially I saw this:

The screenshot above shows that my MacBook Air’s WiFi adapter was receiving Probe Request frames at a signal strength just below -20 dBm.  
After a while, my capture started to look like this:
Notice how the received signal strength is now about 10 dBm higher, hovering around -10 dBm.  That means that my iPad sort of got frustrated with having no AP to associate with, and decided to start using a higher transmit power in the hopes of reaching an AP that is further away.  This behavior is bad for battery life, but would seem to indicate that a 3rd generation iPad can handle connecting to an AP that uses a very high transmit power.
After looking at the iPad, I moved on to my iPhone 5.  My iPhone 5 has a 1 stream 802.11a/b/g/n radio, just like the 3rd gen iPad does.
My initial capture started out looking very similar to the initial iPad capture:
The received signal strength from the iPhone 5 is maybe a few dB lower than the received signal from the iPad, but it’s close.
But then look what happened:

The iPhone started using a LOWER transmit power when sending Probe Request frames.
And then it dropped lower:

And lower:

All the way down until the capture laptop sitting right next to the iPhone was receiving a signal strength below -70 dBm:

Could this be?  Is it possible that iPhones actually lower their transmit power when probing?  In some ways that would be good.  It would mean less interference in large venues like hockey arenas when users fail to connect to guest WiFi.  But in the enterprise it could be bad.  It could result in frustrated users.  A user might be told by support personnel that the WiFi is up and running, but the extremely low transmit power used when doing active scanning (that’s the 802.11 term to sending Probe Request frames in hopes of receiving a Probe Response) could cause the iPhone to think that no APs are nearby.
This was an unscientific test, so there could be other reason for these odd results.  Maybe the iPhone 5 was probing on channel 4 while my laptop was capturing on channel 1.  Maybe the signal strength just appeared to be lower because the channels were off.  Maybe iPhones have different transmit power levels for data and management (which includes Probe Requests/Responses) frames.  Maybe it’s a temporary bug in Apple’s iPhone code that will eventually be changed.
Whatever the reason for the odd changing of transmit power, it is something to take note of if you support iPhones.  And it’s yet another reason that sniffing WiFi often reveals information that is unavailable from vendor documentation.
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 10, 2014 at 12:52 am

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