Just another site

Archive for the ‘MacBook Air’ 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

I Have Seen the Future (of WiFi Sniffing), and It Is OmniPeek (on a Mac)

with 9 comments

Yours Truly has been worried about the future of WiFi sniffing.  Yours Truly worries about the people (they seem to prefer site surveyors) the software (AirMagnet has yet to support 802.11ac adapters) and the methods (WildPackets has been pushing AP-based capture).  To a person who believes that portable WiFi sniffing is essential for optimizing WiFi performance, it is all very disconcerting.  And yet, there is hope.  WiFi sniffing is ready to step into the 802.11ac/Internet of Everything era, and here is how it can be done.

WildPackets OmniPeek has long been the author’s favorite WiFi sniffer, but it only runs on Windows.  For years and years and years that was fine.  There were always a few Windows-compatible WiFi adapters that worked great with OmniPeek.  Now, however, WildPackets has gone in a different direction.  They are promoting WiFi sniffing via an AP (which often results in a worthless capture) and saying that they don’t expect USB-based capture to be viable for 802.11ac.

So, what to do?  OmniPeek only runs on Windows, but they’re not planning to support capture via Windows-compatible USB adapters.

The answer is to switch to a Mac and use virtualization software.  Here is what I did:

1) Buy a Mac

I prefer the MacBook Air because it is cheap, light and cool.  (Literally cool.  Meaning temperature.  The darned MacBook Pro gets too hot to place comfortably on your lap.)

2) Buy Parallels

Parallels is virtualization software and it runs seamlessly on a Mac.  Check out OmniPeek:

You can see the little Apple logo in the upper left, showing that I’m running Mac OS X as I run OmniPeek.
3) Capture in Wireless Diagnostics
I even made a video to show you how!  
In case the video is unclear, you hold down the alt/option before clicking the WiFi icon on the top menu bar.  Then you select “Wireless Diagnostics”, go to the “Window” menu, choose “Utilities”, click on “Frame Capture” and select your capture channel & bandwidth before clicking “Start”.  YOu click “Stop” when you’re done capturing.
4) Open the capture file into OmniPeek
In case the picture above is unclear, you go to the Desktop, right-click on your *.wcap capture file, select “Open With” and select OmniPeek.
5) That’s it!
The limitation of this method is that you’re unable to see live frames as they are captured.  Boo hoo.  (Actually, it’s more than boo hoo.  For certain tasks (like analyzing Probing behavior), not having access to a live capture is a real problem.  But for most tasks, analyzing a capture file after the actual WiFi sniffing is done is just fine.)
On a MacBook Air, the capture I open in OmniPeek is a two-stream, 802.11ac capture.  On a MacBook Pro, it would be a three-stream 802.11ac capture.  That means capturing on an Air will result in me missing data sent and received by a Pro.  Most 802.11a/b/g/n/ac devices will have all of their WiFi traffic captured just fine by an Air, however.
I am still hoping that someone creates a three-stream 802.11ac USB adapter that I can use for OmniPeek (or Fluke AirMagnet WiFi Analyzer, for that matter) capture, but in the meantime these steps will allow you to do useful, portable captures now and in the future.
If you like my blog, you can support it by shopping through my Amazon link or donating Bitcoin to 1N8m1o9phSkFXpa9VUrMVHx4LJWfratseU

Thank you.

Written by sniffwifi

April 23, 2014 at 7:01 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