sniffwifi

Just another WordPress.com site

Archive for the ‘802.11ac’ Category

How Fast Is My 802.11ac WiFi?

leave a comment »

802.11ac is the latest and greatest WiFi standard, but it’s confusing.  So many questions: Is it really that much faster than 802.11n? (It can be.)  Is it worth upgrading?  (Probably not in the enterprise, but at home, absolutely.)  How fast is my device?  (Data rates as low as 6.5 Mbps and a high as 1.3 Gbps.)  

Getting specific answers to 802.11ac performance questions can be a chore sometimes, but there’s a simple way to check your APs.  All you need is a wireless sniffer and about five minutes.

Today I wanted to find out what my 802.11ac AP is capable of.  I suppose I could’ve gone in search of a data sheet, but instead I decided to break out the wireless sniffer.  It was a quick and simple process.

Step 1: Find the channel of your AP

If you’re a Mac OS X user, you can use Wireless Diagnostics.  If you use Windows, then Acrylic WiFi is probably your best option.

My channel was 48.

Step 2: Capture on your channel 

Using a professional protocol analyzer like AirMagnet WiFi Analyzer or WildPackets OmniPeek is usually best.  If you need to keep it free (but remember, free sniffer software almost always means having to spend/waste more time once it’s time to get a job done), then OS X users can use the Wireless Diagnostics Sniffer window and Windows users can install Acrylic WiFi drivers on certain USB adapters and capture into Wireshark.

I started a capture in OmniPeek on Channel 48.

Step 3: Filter on Beacon frames

If you use Wireshark, then type the following in to the Filter text box and click Apply:

wlan.fc.type_subtype == 0x8

I used OmniPeek, so I went to the Filters window (link on the left hand menu bar), opened the Wireless filters and selected the 802.11 Beacons filter.

Step 4: Open a Beacon from your AP

This is the only step where things could get tricky.  You need to make sure that you are looking at your AP and not the neighbors.  In Wireshark that means you might have to try out source MAC addresses until you find one that looks like your AP.

In OmniPeek, I went to the Packets window (again, via the link on the left hand menu bar), enabled the Decode column (by right-clicking any of the existing columns and scrolling all the way to the bottom in order to select Decode) and then selected the SSID field within the SSID information element.  I was then able to see the SSID of every Beacon frame by looking at the Decode column.

Step 5: View the VHT Supported MCS Set

Once you have found a Beacon from your AP, you’ll have to open up the Beacon’s decode and find the VHT Capabilities information element.

In OmniPeek, the VHT Capabilities information element was down towards the bottom.  Once I found it, I opened it up and was able to see the VHT Supported MCS Set.

The key thing to look for is the number of lines that read “10”.  A line that reads “10” indicates that a spatial stream is available.  A line that reads “11” indicates that no spatial stream is available.  That means if three lines read “10” and the remaining five lines read “11”, then there are three (of the possible eight mentioned in the 802.11ac standard) spatial streams available for my AP.

What does that mean for data rates?

1 spatial stream: 6.5 Mbps to 433 Mbps data rates
2 spatial streams: 6.5 Mbps to 867 Mbps data rates
3 spatial streams: 6.5 Mbps to 1.3 Gbps data rates

The reason that multiple spatial stream devices can use single stream rates like 6.5 Mbps is that all 802.11ac devices allow MIMO (the technology behind multiple spatial streams) to be used to improve range instead of speed.  So, my three-stream 802.11ac AP could use its MIMO powers to increase range by keeping the data rate as low as 6.5 Mbps.

This whole process should take you less time than it took to read this blog post (which doesn’t say much about Yours Truly’s relationship with brevity, but I digress).  Once you know what your APs support, it will be that much easier to set up a WiFi network that fits your needs.

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

January 27, 2015 at 12:45 am

Posted in 802.11ac, Data rates

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

Why I Ask Why (And My Review of Matthew Gast’s 802.11ac Book)

leave a comment »

802.11ac: A Survival Guide is a recently published handbook about 802.11ac.  The author is Matthew Gast, a very knowledgeable WiFi guy who follows the IEEE 802.11 Working Group closely.  I recommend the book if you work in WiFi.  It is informative.  There is great attention to detail.  All areas of the subject are covered.  But I was left uninspired.  And my uninspiration (is that a word?) was the result of the book being short on something that I always hope to find in any technical writing: the Why.

In some ways yours truly is the target audience for the book and in some ways I’m not.  I need to know the intricate details of how WiFi works.  (Point)  I already knew most of the tweaks that 802.11ac is making to 802.11n.  (Counterpoint)

The physical layer is the most important part of 802.11ac, and that is where this book wins.  For example, before I read the book I was unaware that 802.11ac allows devices with different channel bonding capabilities can access a wider channel at the same time.  That’s a big deal.  One of my criticisms of 40 MHz channels in 802.11n is that channel space is wasted.  If a device that is only capable of using a 20 MHz channel wins arbitration, then the unused 20 MHz stays vacant.  That’s a waste.  If you use an 80 MHz channel in 802.11ac, two 40 MHz-capable devices can use the channel simultaneously (with a small amount of dead time on one of the 40 MHz spaces), thus keeping the available RF efficient.  Matthew Gast not only explains that concept clearly, but he has great graphics to aid learning.

Unfortunately, the book itself struggles in keeping things efficient.  For example, during the MAC layer chapter the explanation of QoS rambles.  If you understand 802.11e QoS and you understand MU-MIMO, then there’s a 99% chance that you understand MU-MIMO QoS without it being explained to you.  If an AP has frames with varying WMM priority levels ready to send to multiple devices using MU-MIMO, then the lower priority frames are allowed to piggyback on the higher priority frame’s channel time.  That makes sense.  And it makes sense that lower priority frames that would take more channel time than the higher priority MU-MIMO frame are not allowed to piggyback.  It’s a concept that takes a couple of sentences to understand.  In the book it takes two and half pages.

The fundamental reason why the book gets flabby at times is because it could use a little more focus on the Why.  For example, it’s great to list all of the different PHY header fields and options.  But tell me Why first.  I want to know the spirit and the concept of why the architects of 802.11ac designed things the way they did.  Time after time I found myself reading a concept, and then stopping for several minutes to think.  I would try to envision why things are the way they are in the standard.  The book would have been richer if the author would have had that higher level view in the text.

Maybe I’m asking for too much from 802.11ac: A Survival Guide.  Maybe this book is such a technical book with such a specific audience that it should be dry and focused on the facts of the standard.  Maybe it is unnecessary for the Why to be explained.

The reason I was expecting more Why is that I believe that a broad spectrum of people care about the technical details of 802.11ac.  I believe that this book could have been made accessible to a less technical audience without turning off the hardcores.  And I believe that a lot of technical writing — including training courses, study guides and white papers — could be improved by a little more time being spent thinking about the Why.

Written by sniffwifi

December 3, 2013 at 4:10 pm

Posted in 802.11ac, Book reviews

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