sniffwifi

Just another WordPress.com site

Archive for the ‘Probing’ Category

An Android Change for the Better (Maybe)

with one comment

Chatty smartphones have been an issue for years.  Whether you’re concerned with security or performance (or both), the amount of Probing being done by unconnected iPhones, Galaxies and the like has been worrisome.  

Today, things have changed.  Smartphones don’t Probe as much.  This is probably for the better, but there could be a catch.

I’m an Apple guy.  Even when I was using PCs in college (things were different back in the 90’s, I tell ya), it was always because they were free.  Once I finally had to buy a computer, I went straight to the very first iBook in 2001.  I own an iPod, iPad, iPhone and MacBook Air.  My next computing purchase will probably be an iMac (to better record those promised-but-not-yet-delivered online training videos on WiFi that I touted six months ago).  So, I like the company.  And I like bashing its competitors sometimes.  (Not my most magnanimous trait, but nobody’s perfect.)

I liked pointing out that Google’s Android operating system had worst wireless security than Apple’s iOS.  Including:

-Apple requires server certificate validation by default for WPA2 Enterprise authentications (even if it is user-controlled), while Android does not.

-Apple smartphones and tablets Probe only for hidden SSIDs, like so:

(That’s a Probe Request filter in WildPackets OmniPeek.  The SSIDs that you see in those Probe Requests are all hidden SSIDs, with the exception of “Google Starbucks”.  Read on to learn why my local Starbucks’ SSID is showing up in there.)

-Android smartphones and tablets Probe for all saved SSIDs.

At least, they used to.

I was demonstrating the inferiority of Android’s wireless security recently when I learned something new.  They’re not inferior anymore.  Some time recently (or, at least in between the time of my previous Android OS update and my recent update to Android 4.2.2) Google changed Android devices’ wireless behavior to match that of Apple’s.  Android smartphones and tablets started Probing for hidden SSIDs and staying quiet for broadcasting SSIDs, like so:

Of course, I was ambivalent.  GOOD that Android devices’ wireless security has improved!  BAD that I can no longer tout Apple devices’ wireless security superiority in comparison!

So, there you go.  A begrudging admission that Android’s wireless security has been shorn up to match the level of Apple’s.  (In fact, Android’s wireless security is even considered superior in some circles because Android has an option to eliminate user-based verification of server certificates during WPA2 Enterprise authentication.  But we don’t need to discuss that right now.)

But… (and, there’s always a But)

…this may actually be bad for mobility.

Apple iOS and Android devices don’t Probe unless they connect to a hidden SSID.  Nice.  But, let’s take a step back.  Why is Probing in the IEEE 802.11 standard to begin with?

Probing (a process where a client/station device sends a Probe Request frame in order to elicit a Probe Response frame from an access point [AP]) is in the 802.11 standard to facilitate mobility.  Roaming.  Handoff.  Whatever you want to call it when someone moves out of the range of one AP and into the range of another.  Probing also helps devices connect more quickly when starting/waking up and can help devices find an AP in areas that are congested with neighboring WiFi devices and APs.

So, Probing can be a good thing.  Especially for mobile devices in crowded areas.  And now Android devices (like Apple iOS devices) do less of it.

If you say to yourself, “gosh, this iPhone/iPad/Galaxy/HTC One seems to really crap out when I go to a crowded place” (like the Starbucks by my place in Los Angeles), then you might want to ADD Probing to your device.  How?  By tricking your device into thinking that the SSID is hidden.

That’s what I did at my local Starbucks.  My phone sends out these Probe Requests…

…because I manually added the “Google Starbucks” SSID to my phone.  Instead of tapping on “Google Starbucks”, I tapped Settings -> Wi-Fi -> Other… (ellipse in the GUI, not added by me) once I got in line for a Tall Skinny Peppermint Mocha, Hold The Whipped Cream and then typed in “Google Starbucks”.  I don’t know if it helps a whole heck of a lot (Starbucks still uses the darned Captive Portal, which will slow down any wireless connection), but it does optimize a couple of things.
In summary, Android’s move to Apple-like wireless behavior is good for security and overall channel performance.  But if your problems are mobility and speed of connectivity, then you might want to un-do what Android has done by adding your SSID manually.
***
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

Advertisements

Written by sniffwifi

December 19, 2014 at 8:33 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

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

Galaxy Tab 2.0: Probing Done Right (I Think)

with 5 comments

When we last left off, yours truly had noticed that an Android tablet was probing for Wi-Fi networks even when associated.  This behavior would have been unusual, as consumer-grade Wi-Fi devices historically would probe when unassociated and stop probing once a connection is made.  After a little bit more investigation, it appears there was an extenuating circumstance that was causing all of the extra probing.

I wondered if the Android tablet I have (Samsung Galaxy Tab 2.0 with 65 Mbps 802.11b/g/n WiFi) might have its probing behavior affected by movement, and sure enough it does.

I’ll try to amend this blog post later to add screenshots of my captures, but for now here is a summary of what I saw:

I associated my Galaxy Tab to a WLAN that is on channel 1.  Then I captured on channel 11.  My hypothesis is that an associated device should stop probing on other channels as long as the signal is solid.

Sure enough, once I was associated on channel 1, I stopped seeing Probe Requests coming from the Galaxy Tab on channel 11.  In fact, channel 11 showed no sign of the Galaxy Tab whatsoever.  (What was also interesting that is the only SSIDs I saw in the Probe Requests before the Galaxy Tab associated were hidden SSIDs.  Maybe Android has taken the Windows/Apple iOS approach and enabled probing only for hidden SSIDs.  That’ll be another investigation for another time.)

I started walking with the Galaxy Tab, but made sure that I walked only in areas where the received signal was strong (meaning well above -70 dBm).  My channel 11 capture then started lighting up with Probe Request frames from the Galaxy Tab.  The probing was exclusively using the SSID of the WiFi network I was associated to.

The conclusion I reached (at least so far) is that the Galaxy Tab is doing the right type of probing.  The harm of Probe Requests is that they take up valuable channel time and may open up devices to hijacking attacks.  The value of Probe Requests is that they aid mobility.  It appears that when the Galaxy Tab senses movement, the positive aspect of probing is used.  When the device lies still, the negative aspect of probing is avoided (as long as the Galaxy Tab stays associated).

Written by sniffwifi

June 13, 2013 at 11:09 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