Just another site

Archive for April 2010

117 Mbps… But, Why?

with 3 comments

It’s no secret that 802.11n is a peculiar wireless technology. You’ve got multiple transmissions on a channel, a half dozen technologies and a few dozen data rates (at least) for the average AP to choose from. It can all make for some difficult troubleshooting, especially when looking at data rates. Here’s a technique that I use to figure out which 802.11n technologies are missing (or not missing) when I’m trying to figure out why I’m getting a certain data rate.

Now, the first question one might ask when analyzing data rates is, what’s the point? If I’m using my laptop at my desk and I have a 117 Mbps data rate, I’m not going to move to the break room just to get a bump to 130 Mbps. That is certainly true. But from a networker’s perspective, you’d like to give your users the best experience possible, and there may be reasonable changes that would lead to better performance.

There are three questions that you can answer by looking at your data rates. They are:

-How many spatial streams can my device use? It could be one, two or three. Most stations can use two.

-What channel bandwidth am I using? It could be 20 MHz or 40 MHz. The wider bandwidth is only available if there are no nearby 802.11a/b/g WLANs or Bluetooth devices on the same channel.

-Can I use the short GI (guard interval)? This saves the 10% loss in data rate that comes with the standard GI. It’s only available if there are no nearby legacy networks and if there are no 802.11a/b/g stations associated to your network.

If you know your data rate, you can answer those three questions. All you need to remember is the maximum data rates and the 10% rule.

Maximum Data Rates

Here are the maximum data rates for each 802.11n configuration that you’re likely to see:

1 stream, 20 MHz channel, standard GI: 65 Mbps

1 stream, 20 MHz channel, short GI: 72.2 Mbps

2 streams, 20 MHz channel, standard GI: 130 Mbps

2 streams, 40 MHz channel, standard GI: 270 Mbps

2 streams, 40 MHz channel, short GI: 300 Mbps

3 streams, 20 MHz channel, standard GI: 195 Mbps

3 streams, 40 MHz channel, standard GI: 405 Mbps

3 streams, 40 MHz channel, short GI: 450 Mbps

The 10% Rule

Now that you know the different maximum rates (or at least where your bookmark is back to this list), you can apply the 10% rule. The 10% rule just states that in 802.11n, data rates drop from the maximum in intervals equal to 10% of the maximum. That means, for example, that if the maximum rate is 65 Mbps, you could see a lower rate of 58.5 Mbps, 52 Mbps, 45.5 Mbps and so on. Now, not every interval of 10% is actually used in 802.11n, but that doesn’t matter here. You just need to see where your rate fits.

Some Examples

Here is an example of how this works. When I sniffed the frames being received by my iPad, I noticed that a 39 Mbps data rate was being used. I knew that the 10% rule only worked with 65 Mbps, 130 Mbps or 195 Mbps as my maximum rate. That meant that even though my iPad had an 802.11n radio and was associated to an AP using the 5 GHz band, for some reason it was sticking to a 20 MHz channel bandwidth. (I later figured out that the iPad’s WiFi simply eschews support of 40 MHz channels, probably in an effort to save battery life.)

Another example was with my laptop the other day. I noticed that a 117 Mbps rate was being used. Only 130 Mbps and 195 Mbps works with the 10% rule. That made me realize that my laptop was associated to my AP’s 2.4 GHz radio instead of the 5 GHz radio. By switching SSIDs to the 40 GHz radio, my data rate immediately jumped.

Admittedly, this is quite a bit of work in order to figure out something that could be uncovered in most cases by sniffing WiFi frames. And I suppose it’s especially silly to go through this since this blog is supposed to be about sniffing WiFi. Still, I’m all about having multiple ways to skin a cat, and remembering the maximum data rates and the 10% rule is one way to figure out what your 802.11n data rates are telling you.


Written by sniffwifi

April 22, 2010 at 6:24 pm

Posted in Uncategorized

The iPad at Princeton: DHCP Problem/WiFi Problem?

leave a comment »

The Wall Street Journal wrote today that the iPad is having problems on WLANs at the campuses of George Washington and Princeton. While the GW problem has yet to be described in detail, Princeton’s Office of Information Technology has described their problems. The Princeton problem is about DHCP, and it reminded me of another problem that I saw with the iPad’s WiFi behavior.

First, the background. reported that 20% of the iPad’s seen on Princeton’s WLAN had been banned for “malfunctions that can affect the entire school’s computer system.” Then the office of IT at Princeton clarified the issue by saying that iPads continue to use IP addresses after their DHCP lease time expires. This indicates that there is an error in Apple’s implementation of DHCP.

The reason I decided to write about this is that there is an error in Apple’s WiFi that has some relation to the DHCP problem that threatens Princeton’s entire computer system (a tad overdramatic, are we?).

An important note in Princeton’s description of the problem is that the iPad only displays this bad behavior when it is locked. When the iPad is unlocked and active, it renews its IP address when it’s supposed to.

When I found out that the iPad had to be locked to exhibit this bad behavior, I immediately went back to some of the captures that I did on the iPad using WildPackets OmniPeek. I found the exact odd behavior that I remembered about the WiFi: the iPad does not wake on DTIMs like it is supposed to. In fact, there were times that the iPad didn’t wake at all for minutes at a time when locked. This is not supposed to happen if WiFi is implemented correctly in station devices. I don’t know it it’s related to Princeton’s DHCP problem, but they both occur when the iPad is locked.

The way power save mode works with WiFi devices — whether they use 802.11power management (a.k.a. Power Save Polling), 802.11e/WMM Automatic Power Save Delivery or 802.11n Power Save Multi-Poll — is that stations are allowed to sleep in between the DTIM Beacon frames that are send out at regular intervals by the AP. Stations can wake more often than the time in between DTIMs, but they cannot sleep through a DTIM. The reason is that DTIM Beacons contain information about broadcast and multicast data that’s been buffered at that AP. All stations need to hear that.

In any case, the iPad simply doesn’t wake for DTIMs. It sure helps the iPad’s battery life (I can certainly attest to the fact that the iPad seems to stay alive forever when it’s locked), but it violates the 802.11 standard.

Could this problem of not waking for DTIM Beacons end up causing the DHCP problem reported at Princeton? I wouldn’t think so, but then again I don’t claim to be an expert on DHCP. I would think that if the iPad’s DHCP is working properly, it would just renew the IP address when the iPad unlocks. The Princeton report indicates that the iPad is not doing that.

There is one missing piece of information that I’d love to look at, and that’s a frame capture from Princeton’s APs. I do wonder if the APs on Princeton’s network are simply dropping any kind of DHCP lease messages coming from the DHCP server because the iPad is waiting too long to wake up when locked. Again, I am not a DHCP expert so I don’t know if dropped messages from a server could cause this. Still, I’m very curious to know what type of APs Princeton is using and whether those APs drop data that stays in the buffer too long when stations sleep.

For now, this will all have to stay as speculation but if anyone hears more about the nature of Princeton’s WiFi network, email me or drop me a line on twitter (sniffwifi) and I’ll post anything new that I get.

Written by sniffwifi

April 20, 2010 at 12:02 am

Posted in Uncategorized

Apple, I Love Ya But You’re Shady (Another iPad WiFi Complaint)

with 12 comments

If you’re reading this post, there’s a 100% chance that you have heard about the Apple iPad. There’s also at least a 50% chance that you have heard about WiFi problems on the Apple iPad. And there’s about a 10% chance that you’ve heard about the deceptive way that Apple markets the iPad’s WiFi capabilities. That’s what this post is all about.

Apple’s technical specifications for the iPad say that dual-band (2.4 GHz and 5 GHz) 802.11n is supported. And it is. But what Apple doesn’t tell you is that the version of 802.11n built in to the iPad is such that you get almost no speed improvement over 802.11g or 802.11a.

To understand what’s going on with the iPad’s mediocre 802.11n design, you have to understand a little bit about what goes in to 802.11n. There are three 802.11n improvements that bump up the maximum data rate from the 54 Mbps we had with 802.11a/g: more efficient (5/6 instead of 3/4) OFDM coding, double-wide (40 MHz instead of 20 MHz) channels and MIMO antenna systems (for spatial multiplexing). (And yes, I realize that the short guard interval can also improve data rates, but let’s pretend we live in a world where there is always a legacy a/b/g device sharing our BSS.) Let’s talk about each of these things individually and whether the iPad supports them.

Let’s start with ODFM coding improvements. Having more efficient OFDM coding allows the data rate to jump from 54 Mbps to 65 Mbps (assuming a single spatial stream, which I’ll talk about later). The ratio in OFDM coding refers to the number of bits read as data over the number of bits transmitted in the code. Therefore, a higher coding ratio means that more transmitted bits will be read as data. In the case of 802.11n, we are getting 83% (5/6) of the number of our transmitted bits read as data rather than 75% (3/4). This is required in 802.11n. When you sniff the iPad’s Probe Request frames (informational frames about the station’s capabilities) it shows as supported and when you look at the iPad’s data frame behavior it is supported as well. (That’s good!)

Next is the improvements from having a wider channel. Having double-wide channels allows the data rate to jump from 65 Mbps to 135 Mbps (again, assuming one spatial stream). The normal 802.11a/g channel is 20 MHz wide and 802.11n allows the channel bandwidth to be 40 MHz instead. The way this affects data rates is that you double the rate and then add 5 Mbps for each spatial stream. The reason you get the extra five is that a double-wide channel makes more efficient use of the bandwidth because you only have two channel edges in that 40 MHz space rather than 4 (just think about it for a second, it’ll make sense). This is not required in 802.11n and the iPad’s Probe Request frames show it as unsupported. This causes the speed to be lowered, but could also cause the battery life to improve. I guess that’s good, but I feel deceived. If you want to give me better battery life you can do it, but when I buy an 802.11n product I expect a maximum data rate of at least 300 Mbps. Without double-wide channels, the iPad has no chance of exceeding 130 Mbps.

The last major 802.11n improvement is having MIMO antenna systems for spatial multiplexing. Spatial multiplexing sounds complicated, but it really just means having double (or even triple or quadruple, depending on the device) the data sent over a single channel. It just means that your two (or even three or four, again depending on the device) antennas each send their own stream of data on the same channel at the same time. The way this affects data rates is that they double (or triple or qua– …you get where I’m going here). So the 135 Mbps I’d get from a device that also supports more efficient OFDM coding and double-wide channels would jump to 270 Mbps (or 405 Mbps, or 540 Mbps…). This part of 802.11n is required (at least for 2 streams; 3 and 4 streams are optional) and the Probe Requests from the iPad show that it is supported. BUT IT’S NOT ACTUALLY SUPPORTED! How dare you, Apple! You’re cheating the 802.11n standard and, more importantly, you’re cheating the 0.001% of your most brainwashed loyal customers who buy anything you release the day it goes on sale.

So what does all of this mean? The bottom line is that you are getting 65 Mbps 802.11n with the iPad, not 300 Mbps like with most Apple stations. 

Does this really matter? The reality is that it doesn’t right now. As much as I hate to say it, I like what Apple is doing from a pure practical perspective. The reality is that you don’t need more than a 65 Mbps data rate for any application the iPad runs. You would want the enhanced range of 802.11n (and the improved receive sensitivity of MIMO will help you with that), but you don’t really need the higher speeds. So by killing spatial multiplexing Apple is robbing you of something you don’t really need but giving you something you do (better battery life). 

At this point it may seem odd for me to call Apple shady for giving you a version of 802.11n that fits the iPad better than the plain ol’ standard. I can see that. But I just wish they’d be a little bit more straightforward in their marketing. If you’re going to give us a technically-standard-but-really-not-supporting-what-is-supposed-to-be-required-in-the-standard version of 802.11n, just tell us. Tell us that you’re helping our battery life while still giving us adequate speeds for the apps we’re gonna run and you’ll get us nitpickers on your side.

Written by sniffwifi

April 12, 2010 at 2:16 am

Posted in Uncategorized