Just another site

Archive for the ‘iPad’ Category

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

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

Sniff Like Silver

leave a comment »

Sometimes I dream
That he is me
You’ve got to see that’s how I dream to be
The dream I riff, the dream I sniff
Like Nate
I want to be like Nate (Silver)

Much has been made of the increased emphasis on statistical analysis, especially in the wake of New York Times blogger Nate Silver correctly predicting the electoral results for all 50 states in the recent United States presidential election.  Can analytics be applied to WLANs?  Of course they can.  It’s just a matter of sniffing the right stuff.

There are a lot of bad WiFi networks out there.

There.  I said it.  It’s out there and I can’t take it back.  I see a lot of Wi-Fi in my travels.  Almost all of it could be improved upon and much of it seems like it was installed by folks with little understanding of how 802.11 networks work.

So, what do we do to fix it?

We can have best practices.  We can finally ditch automatic RF controls.  (Please, people.  If you haven’t head yet, you want to set your 2.4 GHz channels to 1, 6 and 11 only and you want to keep your AP transmit power between 12 and 15 dBm.)  We can embrace directional antennas.  We can stop thinking that the solution to poor client/station connectivity is to place another AP nearby.  But what does that solve?  Are we really getting to the core of the problem, or are we just playing Whack-A-Mole?  (It’s a fun children’s game where you use a foam hammer to hit Moles that pop up, but whenever you whack one mole, another is certain to surface.)

If you really want to improve WiFi, you need to know how WiFi works.  The Boston Red Sox (gosh I hate the Red Sox so this next part is really, really, really painful to write) studied how baseball works, and they went and signed David Ortiz.  (Who was RELEASED by the Twins!  Hahahaha!  Reveling in the Twins’ incompetence is almost enough to make up for having to praise the Red Sox.)  They picked up Keith Foulke and Kevin Millar and Curt Schilling.  They analyzed how baseball works (in their case, that meant looking at historical statistics in an attempt to identify what statistics tended to identify players who contribute to winning teams) and they applied what they learned when building two World Series champion baseball teams.

So we need to know how WiFi works.  Great.  Now how do we do that?

Part of knowing WiFi is understanding the 802.11 standard.  (WARNING: shameless self-promotion coming)  If you are unfamiliar with the standard, a great place to start is the CWNA Study Guide and a great place to finish is the CWAP Study Guide, which I am a co-author of.  (See, I told you this would be disgusting self-promotion.)

The other part of knowing WiFi is understanding how your devices work.  Not just the APs.  The client/stations.  You want to figure out how your iPads, iPhones, Kindles and Blackberrys are going to act.  What will my iPad do when it wakes from sleep?  When I enable the WiFi radio?  When I put it to sleep?  When I open the Twitter app?  When I download the Wall Street Journal?

Nobody has the time to sniff every possible activity that every possible device could possibly endeavor.  But we can sniff some of it.  If I work at a university, I can sure as heck see what iPads do when they go to sleep and wake from sleep, because that will probably happen thousands of times per day on my campus.  If I work at a hospital, I can run the Andoid app that some of my doctors use to view doctor-y stuff.

To engage in WiFi client/station analytics, one should really use a professional tool like WildPackets OmniPeek, but you can do this stuff with free tools like Wireshark.  For example:

If I have a laptop or desktop running Mac OS X, I can hold the [Alt] key while clicking the signal bars and then select Open Wi-Fi Diagnostics.  I’ll get a screen that looks like this:

I can then select Capture Network Traffic and click Continue.  That takes me to this screen:
To sniff WiFi properly, one needs to be in Monitor Mode (NOT promiscuous mode).  To get Wi-Fi Diagnostics to use Monitor Mode, I select Capture all data from all nearby networks and then I select a specific channel.  (The office I’m working from today is using channel 2 and that’s just silly but that’s another story for another blog post.)
Once I have set up a Monitor Mode capture, I can then click Start Capturing.  From there, I just do what I would normally do.  I put my iPad to sleep, I woke it up, I turned on airplane mode, I turned on and off the WiFi radio and I ran the Twitter app (say hello to me on Twitter sometime at @Ben_SniffWiFi).
After you finish capturing the Wi-Fi Diagnostics application will zip up all of your diagnostics information and give you a .pcap file like so:
Open that file and, voila!, you have a Monitor Mode capture that you can use to analyze your WiFi client/station’s behavior.
Now, as any person who embraces analytics will tell you, gathering the data is the easy part.  What separates the Red Sox (grrr!  Hate to give them credit) from the Twins (hah hah!  Brewers rule and you know it) is the ability to understand which parts of the data are useful and which are not.  And that, my dear readers, is a topic for another time and place (and maybe, a blog post).

Written by sniffwifi

January 3, 2013 at 7:50 pm