Just another site

Archive for the ‘iPhone 5’ Category

Why Are You Slowing Down My WiFi, Apple? To Make Things Better?

with 4 comments

I defend Apple a lot.  When Network World wrongly accused the original iPhone of flooding Duke University’s network, I defended Apple.  (It was later found to be a Cisco problem.)  When a health care provider I was doing some work for blamed SIP-enabled iPhones for a VoIP problem, I eventually found out that the APs were to blame.  (The APs were failing to respond to WiFi frames tagged as “Background” QoS.)  Time and time again networking folks blame device makers like Apple, and time and time again the problem ends up being the network.

There are times, however, when it really is Apple’s fault.  When the network is operating just fine.  This is one of those times.  The problem is that I just don’t know why.

802.11n (HT) and 802.11ac (VHT) networks operate in co-existence with first generation (802.11a/b/g, that is) WiFi a lot.  When that happens, the HT or VHT access point operates in mixed mode.

There are all sorts of ramifications when a WiFi network operates in mixed mode, but one of the bigger ones (a ramification that usually results in a throughput loss between 25% and 40%) is the protection mechanism.  When the the AP operates in mixed mode, it transmits data using the protection mechanism and it uses Beacon and Probe Response frames to tell WiFi devices to use the protection mechanism.  An AP or device using the protection mechanism will precede its data frame transmissions with the transmission of a non-data carrying frame called a request to send (RTS) or a clear to send (CTS).  The RTS and CTS frames are always sent at a data rate that the legacy devices can understand.  For example, a WiFi network with a mix of 802.11a and 802.11ac devices would see 802.11a (24 Mbps, typically) RTS and/or CTS frames sent in advance of data that would be sent using VHT rates (up to 1,300 Mbps with today’s gear).

An important note in all of this is that if there is no mixed mode, then there doesn’t need to be any protection mechanism.  If you’ve got a bunch of HT devices all associated to an HT AP, then there shouldn’t be any RTS or CTS frames slowing down the data.

Rough & Tumble Films (a movie production company whose owners I’m friends with and who have a little country noir called “We Gotta Get Out Of This Place” airing on the Starz network later this year) has a WiFi network with an HT AP and all HT (or VHT) devices.  (See the Probe Request frame below showing the “R&T” network indicating that all devices are HT-capable.)

The R&T WiFi network should see HT data frames going across the WiFi channel without any RTS and/or CTS frames slowing it down.  That is not, however, what shows up in my WildPackets OmniPeek capture.  (See that the highlighted data frames below are sent at HT rates of 243 Mbps and 300 Mbps, but they are surrounded by RTS and CTS frames sent at 24 Mbps.)

What gives, I wondered?  Are the Probe Response frames coming from the AP giving me bad information?  Are devices acting up?  My initial capture was done on data going to and from my laptop (MacBook Air using dual-band, two-stream 802.11n), so I wanted to add my phone to the network to see if anything was different.

When I added my phone (iPhone 5 using dual-band, single-stream 802.11n), the same behavior occurred.  More 24 Mbps RTS and CTS frames were surrounding my HT (this time 135 Mbps or 150 Mbps) data.

I noticed a trend when investigating all of this protection mechanism traffic on my friends’ non-mixed mode WiFi.  I noticed that the RTS frames were only being sent by my devices.  The APs were never sending an RTS frame.  Beyond that, I noticed that when the AP was the transmitter of a data frame, neither an RTS or a CTS preceded that data frame.  In short, I noticed that the AP was not using the protection mechanism, which my laptop and phone were.

I know, then, that Apple devices (both iOS and OS X) slow down the channels they are using by acting like it’s mixed mode even when it’s not.  What I don’t know is, Why?  Did Apple make a mistake?  Is there some HT or VHT protocol that I am unaware of that causes devices to use the protection mechanism even when APs don’t?  Or is Apple doing this on purpose because someone at Apple thinks that their devices function better when the protection mechanism is always on?

After seeing Apple devices voluntarily engage in the protection mechanism, it made me think back to a question that I received while doing a Reddit AMA last year.  A person asked about RTS/CTS being used to manage network traffic and getting devices to cooperate.  The person from Reddit mentioned that he (sorry ladies, but when his Reddit handle is “ShadowHawk109” and he posts about beer, WiFi and William Shatner, it’s got to be a guy) did work in academia, so I just assumed that he didn’t know what he was talking about.  Maybe he was on to something.  Maybe Apple believes that their devices will have a more consistent data connection over WiFi if RTS/CTS frames are being used all the time, and so they’ve enabled it in their devices.  Maybe Apple doesn’t care that much if their devices cause the maximum available throughput to be lower on the channel.

Whatever the reason may be that Apple devices have been programmed to use RTS/CTS frames, WiFi professionals are going to have to deal with the impact.  It could mean that our throughput tests mean even less and that our ability to support high density deployments has been expanded.

If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

Written by sniffwifi

May 30, 2014 at 12:00 am

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

Sometimes, Two Plus Two Ain’t Four

leave a comment »

My love for WildPackets OmniPeek may be one of the few things in technology that exceeds my love for the iPhone…

Now that I’ve run off 20% of my audience, let’s talk about how the former can be used to figure out if the latter is causing a problem.

I have a lot of enemies in life, and I’m proud of that.  In my opinion, part of being an adult is recognizing who your enemies are.  UCLA football players are my enemy when they play college football.  Drivers who text while stopped at green lights are my enemy when I am running late.  (No comments from the peanut gallery on that one, GT Hill.)  And deductive reasoning is often my enemy when troubleshooting.
Deductive reasoning is oh so tantalizing.  It’s simple math; A + B = C.  The WLAN works (C) when VoFi handsets (B) connect to my APs (A).  If I switch out the VoFi handsets for SIP-based iPhones (thus changing the value of B) and the WLAN stops working, then the iPhones must be at fault.  Right?  Wrong.
Deductive reasoning only works if you eliminate all variables but one.  A switch from a VoFi handset to an iPhone is not the changing of one variable.  It is the changing of numerous variables.  The chipset changes.  The client utility changes.  The apps that run in the background change.  The SIP app changes. 
Another problem I have with deductive reasoning is that sometimes a device that we think is working really isn’t working.  That’s what was happening recently when I was doing some work on site at a health care provider.
The Problem

The health care provider had been using dedicated VoFi handsets for years.  Like many organizations, they decided to move away from dedicated voice devices and use a smartphone app instead.  In this case, it was an Avaya smartphone app running primarily on iPhone 5s.  
Once the iPhones started getting used, the WiFi folks at the health care provider immediately starting noticing problems.  Users were saying that the phones kept beeping.  Avaya said that the app will cause the phones to beep if the app gets disconnected.  It is a way to protect phone from being stolen or taken to locations where they’re not supposed to go.
The problem for the WiFi admins is that the phones were still connected when the beeping was happening.  Something was causing the iPhone to think it was disconnected when it really wasn’t.
Faulty Deductive Reasoning

The natural reaction of the WiFi admins was to blame the iPhones and/or Avaya.  The health care provider had a working VoFi solution.  They changed to iPhones and Avaya.  The solution stopped working.  The rest of the WiFi continued to work well, so the problem was thought to be the phones.

I was skeptical that the iPhones and the Avaya app were the problem right from the beginning.  iPhones have been blamed innumerable times over the years for problems that were actually the infrastructure’s fault.  What’s more, I tend to almost always blame the network.  My attitude is that networking (both wired and WiFi) is the business of support.  We don’t make money for the company.  We create infrastructure that allows saleswomen and craftsmen (see what I did there, ladies?) and executives to make money for the company.  If a user wants to use a certain device, we should try to make our infrastructure support that device.  (That is, assuming we want the company we work for to grow and be successful.)
OmniPeek to the Rescue

Armed with my natural skepticism of iPhone blame syndrome, I had the lead WiFi guy do an WildPackets OmniPeek capture with me.  (OmniPeek is the WiFi sniffer that he was already using.)  We set the capture to the channel of the nearest AP.  We associated the iPhone.  He made an received a call.
We then looked at the OmniPeek WiFi statistics (Summary -> 802.11 Analysis, for those of you OmniPeek users).  I noticed that the Retry percentages were astronomical.  Getting as high as 60% at their worst.  That told me that something was wrong.  During normal operation the WiFi channel was seeing Retry percentages well below 10%.
From the Summary screen of OmniPeek, we switched to the Packets screen to get more detail.  I turned on Auto Scroll (a little icon above the packets list that looks like a little padlock) and watched the packets come in while we repeated our iPhone test.  I kept my eye on the Flags column in my Packets window because I knew that Retry frames always caused a red colored “+” to show up in that column.
Sure enough, the next time the iPhone connected a whole slew of frames with a red “+” showed up in the Flags column.  I saw more than 5 consecutive HTTPS frames in a row all with the Retry flag and none of them were followed by acknowledgment (802.11 Ack) frames.

We Found a Problem, but Whose Fault is It?

Once we saw a flood of unacknowledged frames, we had to determine what the cause might be.  Was it the iPhone misbehaving?  A bad Avaya app?  Or the AP being unresponsive.

All of the Retry frames had the iPhone 5’s MAC address as the second address in the 802.11 header.  The second address is always the transmitter’s MAC address.  That meant that the iPhone was sending all of the frames that were failing.

After seeing that the iPhone was the device that was sending the failed data, I immediately began to suspect that the APs were the problem.  It is quite rare that a device will disconnect itself while sending a bunch of data at the same.  Remember, our initial problem was that we were getting a beeping sound that indicated a network disconnection.

Let’s Get Specific

Blaming the WiFi infrastructure for an iPhone problem is always satisfying (at least, if you’re an Apple loyalist like yours truly), but in order to get people to believe you it’s best to pile on the evidence.  My usual method is to try to find something logical.  Why would an AP just stop acknowledging iPhone data?  Why might I be using the same WiFi APs and controllers that have always worked fine with VoFi handsets and never see a problem that is the fault of the infrastructure?

I used OmniPeek to look inside the frame decodes for any unique properties of the unacknowledged frames.  I noticed that some of the problem data had the same WMM/QoS category in the QoS Control field: Background.  I immediately added the Decode column to the OmniPeek Packets screen, then selected the Traffic Identifier (TID) subfield within the QoS Control field of the 802.11 header.  In the Decode column of the OmniPeek Packets screen, whichever field or subfield selected in the frame decode below will be displayed.  So in my case, that meant that the Decode column displayed the TID for every frame.

Once I was able to easily see the TID for each captured data frame, I started quickly scrolling up and down through the capture.  Sure enough, I saw a consistent pattern.  Every time the iPhone sent a frame tagged with the Background TID to the access point, the access point would fail to send an acknowledgment in return.  We didn’t have time to identify which specific app within the phone was sending data tagged as “Background”, but at that point it was peripheral to the issue.  If an AP can’t handle Background traffic, then that AP is a potential problem that could spread beyond just iPhones and Avaya apps.

The Conclusion

The lead WiFi administrator was in the room with me looking at OmniPeek as we were investigating this iPhone disconnection problem (and, unfortunately, this is why I am unable to show screenshots of our OmniPeek captures).  He came into the day looking for an iPhone problem.  After an hour or so of using OmniPeek, he realized that the problem was his APs.  The fact that he was using 802.11a/b/g APs made things all the logical.  The AP vendor had mentioned to the lead WiFi admin that those old APs were no longer receiving firmware updates and that it could lead to problems.  Our little OmniPeek exercise convinced him that it was either time to upgrade or to look for a new vendor (and his current AP vendor shall go nameless in this blog post, because I like to avoid trashing vendors for hardware or software that is no longer kept up to date).

I am aware that I sometimes come across as too sniffer-centric.  I realize that some people find management software easier to access or spectrum analyzers easier to understand or discovery software easier to afford.  But there is a reason that I am such a zealot for WiFi sniffers.  They help me identify causes of the really difficult problems that plague so many high level wireless networks.

Written by sniffwifi

November 11, 2013 at 11:37 pm

Posted in iPhone 5, OmniPeek, VoFi

Eighteen Seconds of (a Very Chatty) iPhone

leave a comment »

The iPhone 5 is a chatty device.  How chatty?  I checked, and it is chattier than I thought.

Yours truly has done more WiFi sniffing of iPhones than yours truly cares to recount.  What has always stood out about these captures is the amount of chatter than an iPhone seems to engage in.

I did a little test of my unlocked iPhone 5 to see exactly how chatty it was.  The test involved me turning on the phone’s screen, spending a second looking at iMessage (which happened to be the last app I was on when the screen was turned off), pressing the Home button, opening the Twitter app (because, after all, if you’re not on Twitter these days then you’re not wasting your time properly) and refreshing my Twitter feed.

The test took about fifteen seconds.  My capture saw WiFi frames going to or from my phone for about 17.64 seconds (rounded up to 18 for the purposes of a catchier blog post title).  Here is what it looked like:

The good news is that my phone was using high rates for data.  The highlighted frame above traveled through the air at 121.5 Mbps.  Some of the data frames even went all the way to the iPhone 5’s maximum data rate, which is 150 Mbps.  (And pay no attention to the 6 Mbps or 24 Mbps frames.  That’s control traffic.  Nothing you can do to escape that.)

The bad news is that my phone was very active on the channel despite the fact that all I really did was turn the thing on and refresh my Twitter feed.  Check out the stats from my capture:

The “Displayed” statistics are representing my phone’s traffic only.  And what happened in that 17.6 seconds?  268 kB (or, 0.268 MB if you want to look at it that way) was send across the wireless channel.  That is a pretty large amount of stuff for a simple Twitter feed refresh.  Imagine if I tried to look at a photo or browse the web.

So the iPhone is a chatty Cathy.  It’s not very chatty when the screen is off (unseen above is the fact that the first frame with my phone’s address was sent a full 10 seconds after I started capturing, which coincides with the time I turned on the phone’s screen), but once people start using their iPhones those babies get active even when the user isn’t very active.

What does all of this mean to us?  One thing it means is that conserving battery life ain’t just for the Sierra Club.  Users who keep their screens off are also keeping our WiFi networks clear.  The other big takeaway is that app developers don’t care about us.  They’re gonna make their apps the way they want to make their apps.  I’d bet dollars to donuts (a cliché that no longer makes sense, but still) that developers from Twitter and Apple could have made the iPhone 5 a lot less active on the WiFi channel if they’d have wanted to.  Typically it takes a crisis for app developers to reel in their network consumption.  Who knows if that will happen any time soon.

Written by sniffwifi

August 30, 2013 at 10:52 pm

Posted in iPhone 5, WiFi traffic

OmniWiFi USB Adapter and OmniPeek 7.5: Compass is King

with one comment

As long time readers of this blog might know, WildPackets OmniPeek has been my favorite WiFi sniffer for nearly a decade.  Then I found out about WildPackets’ OmniWiFi 3-stream 802.11n USB adapter and I fell even more in love.  Now I learn that OmniPeek 7.5 has added wireless features to the Compass screen.  A good product has been made better (though time will tell if it lasts).

First, OmniWiFi:

The fact that different 802.11n devices have different capabilities is one of those things that sometimes flies under the radar.  The standard may say 600 Mbps, but just on the Apple website one can buy 802.11n devices with maximum rates of 65 Mbps (iPhone 4S), 150 Mbps (iPad Mini), 300 Mbps (Macbook Air 2012) and 450 Mbps (Macbook Pro 2012).

450 Mbps WiFi devices are the ones that give WiFi pros trouble because so many sniffing tools fail to capture 450 Mbps traffic.  The popular (at least with Wireshark devotees) AirPcap NX from Riverbed, the beloved (at least by yours truly) D-Link DWA-160 and the hacker-ish SR71-USB from Memphis Grizzlies owner Robert Cera’s Ubiquiti Networks all are dual-band 802.11a/b/g/n USB adapters that can be used with WiFi sniffing software, but none of them can capture 450 Mbps data frames.  Those adapters all have two radio chains (and thus, can capture two-stream 802.11n) and 450 Mbps traffic uses three-stream 802.11n.

OmniWiFi is a USB adapter that gives WildPackets OmniPeek users the ability to capture three-stream 802.11n traffic.  It also dynamically adjusts its capture settings when 802.11n traffic is in the air.  When my iPhone was sending and receiving data frames over a 40 MHz channel, OmniWiFi captured all 40 MHz.  When my acknowledgment, request to send or clear to send frames went out on a 20 MHz channel, OmniWiFi caught that as well.

The limitation of OmniWiFi is that it is 802.11n, and the consumer side of WiFi is moving towards 802.11ac.  Management frames and most control frames will still be captured with OmniWiFi.  Data frames over WLANs that have yet to upgrade of 802.11ac access points, as well.  The problem is that if a coffee shop on the ground floor of an office building decides to buy a new Apple Airport Extreme, you won’t be able to tell exactly how the data traffic going to and from a new Macbook Air is affecting your WLAN.

When I spoke to a representative from WildPackets, I was told that an 802.11ac version of OmniWiFi might be in the works.

To repeat:  When I spoke to a representative (someone whose job description presumably includes promoting the company) from WildPackets (the company who makes the best enterprise-grade 802.11n WiFi sniffing solution), I (a WiFi sniffing blogger) was told that an 802.11ac (the hot new standard) version of OmniWiFi (the best wireless hardware ever created by the company) might (as in, might-or-might-not) be in the works.

What the heck?

When I was told that an 802.11ac version of OmniWiFi was not a certainty, I sort of couldn’t believe it. The WildPackets rep (a technical guy who knows 802.11 quite well) shoveled over some mumbo-jumbo about OmniPeek capture support in 802.11ac access points (from Ruckus Wireless) and the speed limitations of the USB 3.0 interface (and I was proud that I avoided giving my stump speech on the lack of value in throughput tests in response).  He said that USB-based wireless capture was limiting, and that most WildPackets customers prefer to capture from APs, anyway.  Great.  Fantastic.  But how about using a WiFi sniffer to solve the tough problems?  That requires field work.  That requires a portable device from which to capture.  That is not the type of thing you do from an AP.

I am going to enjoy OmniWiFi while 802.11n continues to be relevant, but I really, really, really hope that WildPackets pushes Ralink (makers of the current 802.11n OmniWiFi chipset) to make a USB adapter that does 802.11ac capture.  I don’t want to have to write a blog post titled, “Worthless Capture, Part III”.

And Then, OmniPeek 7.5:

My conversation with the WildPackets rep also covered OmniPeek 7.5.  If you are a user of OmniPeek Basic ($1,200 USD), then you can skip the rest of this blog.  OmniPeek 7.5 doesn’t add anything all that new.  The Packets screen has a new MCS (modulation and coding scheme) column and a new Spatial Streams column (see below).

Neither the MCS column nor the Spatial Streams column works, so forget it.  Maybe OmniPeek will get things going in a future update, but that picture above clearly shows 54 Mbps (which could be single stream 802.11a/g or dual stream, MCS 3 802.11n) data and it clearly shows no indication of which type of 54 Mbps data it is (answer: 802.11n.  Now can you tell me in the Comments how I know that from looking at JUST THE PACKETS in this capture…?).  (To be fair, the WildPackets rep used Go To Meeting to show me a capture that had information in the MCS and Spatial Streams columns.  It did not work for me, however.)
For those of you that use OmniPeek Pro ($3,000 USD) or OmniPeek Enterprise ($6,000 USD), there is something new in version 7.5, and it involves the Compass.
The OmniPeek Compass is something that has been present in OmniPeek, but I never used to use it because it didn’t give me relevant WiFi information.  I want to know Data Rates.  I want to know Retry percentages.  I don’t care about Mbps averages or conversations.  Save that for wired sniffing.  Wireless sniffing should be all about wireless (connection, performance, security, etc.) analysis.
OmniPeek Compass now shows data rate and retry information, and it is great.  
Let’s take an example.  Say I have a smartphone that is having WiFi problems.  I can create a couple of smartphone filters (one for data coming to my smartphone and one for data coming from my smartphone) and then go to Compass.  First I apply one filter (To the phone) and then the other (From the phone).  I can then track what rates are typically being used in both directions.
The screenshot above shows that my smartphone is using higher rates than my AP.  On the left hand side (in the area where I was applying the To Phone filter) the maximum rate fluctuated between 54 and 81 Mbps (MCS 3 and 4).  Once I switched to the From Phone filter, the maximum rate immediately spiked to being between 81 and 108 Mbps (MCS 4 and 5).  That tells me that my phone is very aggressive in trying to send data at high rates.
A quick flip of the Compass screen from Rates to Retries allows me to see if my smartphone’s use of high rates has consequences.
Again, the To Phone filter was applied first (on the left of the graph) and the From Phone filter was applied after (on the right).  Data going to my smartphone was almost never retried (which made sense, since the office uses a 5 GHz channel that is unoccupied by any other WiFi networks).  Once the filter switched to data being sent by my phone, Retries started to show.  The percentages were still below 8% (which is the rule-of-thumb number I use to determine if Retries are a problem), but they were still there.  It means that, at least for the application I was running for the test, the iPhone 5 might be a little bit better off using lower rates so that Retries can be almost entirely eliminated.
That is just one example.  One of the best things about OmniPeek is the myriad ways that filters can be configured and applied, and Compass is a perfect place to see what those filtered devices and protocols are doing in real time.
OmniPeek 7.5 is worth having, but it could still be improved.  I’d still like to see WildPackets copy off of the superb work that Metageek did with Eye P.A. and add a Time metric in addition to Packets and Bytes.  OmniPeek also needs to give better breakdowns of exactly how many packets or bytes are using which data rates.  Still, it remains a great tool and the additions to Compass in version 7.5 make it even more useful.

Written by sniffwifi

July 1, 2013 at 11:47 pm

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