sniffwifi

Just another WordPress.com site

Archive for the ‘802.11n’ Category

What’s New (and Missing) in the WiFi for iPhone 6

with 3 comments

Two years ago tomorrow Apple introduced the iPhone 5.  It was a big deal.  It was a big deal for gadget folks who wanted a bigger iPhone.  It was a big deal for wireless LAN folks who wanted users to use smartphones with speedier WiFi.  

Now the iPhone 6 has been announced and it appears to be more of the same.  Gadgeteers get their bigger iPhone.  Wireless folks get their faster speeds.  Problem is, the faster wireless speeds likely won’t mean anything for high capacity wireless deployments.

The big news about the iPhone 6 is 802.11ac.  Yippee!  Apple has finally adopted the latest and greatest WiFi standard in a mobile device.

802.11ac has data rates as high as 6.9 Gbps in the standard, but wireless LAN folks know that’s not what happens in real life.  Real 802.11ac devices top out at a 1.3 Gbps data rate when multiple input-multiple output (MIMO) antenna systems are supported, while non-MIMO devices top out at 433 Mbps.

The iPhone 6 and iPhone 6 Plus are non-MIMO 802.11ac devices.  That means a top rate of 433 Mbps.  That is higher than the top rate of the 802.11n-supporting iPhone 5 and iPhone 5S, which is 150 Mbps.  And that is where Apple gets the nerve justification for putting this on their site:

You see, 433/150 = almost 3.  That means three times faster wireless!  Except it doesn’t.
802.11ac is basically the same thing as 802.11n.  I know that 433 and 150 seem like very different numbers, but in most real world cases, they’re actually the same.
Here’s how it works:
802.11n = 150 Mbps –>

–> Normal 802.11ac = 150 Mbps –>

–> 802.11ac with clear line of sight and a distance less than 30ft/10m = 200 Mbps –>
(That’s because when you’re that close and there are no obstructions, then 802.11ac can use a technology called 256-QAM, which allows waves to carry 8 bits of data rather than 6 bits.  8/6 = 200/150, so that means that adding 256-QAM boosts the top data rate to 200 Mbps.)
–> 802.11ac with clear line of sight and a distance less than 30ft/10m and 80 MHz channels enabled = 433 Mbps
(80 MHz channels are no good for high capacity WiFi.  Instead of being able to split users up amongst 9 [if disabling dynamic frequency selection {DFS}] or 21 [if enabling DFS] channels, an 80 MHz wireless network only has 2 [non-DFS] or 4 [DFS] channels.  And here in the U.S. of A., our beloved FCC regulatory commission just made it a whole lot harder to use DFS channels because of Item 67 in the 2014 updates to UNII rules.)

Think about the average high-capacity wireless network.  Do the users have a line of sight to the APs?  Usually, No.  Are the users within thirty feet (ten meters) of the APs?  Often, No.  Is it better to spread users out among four or five times as many channels?  Definitely, Yes.  If you agree with these answers, then 802.11ac in the iPhone 6 and iPhone 6 Plus reverts to the 150 Mbps data rates used in the iPhone 5 and iPhone 5S.

A year ago, yours truly wrote that non-MIMO devices were going to be around for a while.  MIMO drains battery life faster and it can cause a device to heat up.  So, the lack of MIMO in the new iPhones is no surprise.  But it is disappointing.  And it comes down to this:

802.11n w/ MIMO > 802.11ac w/o MIMO

The iPad Air, which has been out for about a year now, is a mobile device from Apple that supports MIMO.

In a typical high capacity WiFi environment, the iPad Air or iPad Mini is going to get as high as 300 Mbps in the 5 GHz band or 144 Mbps in the 2.4 GHz band.  The iPhone 6 or iPhone 6 Plus is going to get as high as 150 Mbps in 5 GHz, or 72 Mbps in 2.4 GHz.  That’s big.  It’s big for users of the gadgets and it’s even bigger for the WLAN folks who have to manage those networks.  Apple may have done a solid for people who want to be able to see five Tweets on their screen at a time instead of four, but for wireless folks who have to deal with high capacity networks they didn’t help us out as much as they could have.

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

September 17, 2014 at 7:04 pm

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