Just another site

Archive for January 2011

WiFi In The Arena

leave a comment »

UFC 125 happened on New Year’s Day, and I was fortunate enough to cover the show for the Wrestling Observer. As with just about every sporting event nowadays, the MGM Grand Garden Arena provided WiFi service for the members of the media who were covering the event. I managed to squeeze in a little bit of sniffing while I was doing my live blog, and the results I found were a little bit surprising to me.

When I think of public Wi-Fi, I think of downloads. Maybe that makes me an old codger, but I just imagine all of these web pages, videos and spam emails coming down with just a few requests and acknowledgments going back up. The world has changed, of course, with more people than ever wanting to tweet, blog and upload photos as part of the social media revolution, but I still was dubious when Andrew Von Nagy (@revolutionwifi) told me on Twitter that I should expect a pretty even distribution of data on any public WiFi network nowadays.

Sniffing in the media area turned out to be a bit of a chore. When I got cageside (after a scrumptious fajita lunch in the press room; thank you, UFC), I immediately booted into Windows 7 and broke out my trusty WUSB600N adapter so that I could run WildPackets OmniPeek. At that point I slid on over to the WLAN screen (SSIDs/APs/stations) of OmniPeek to find my laptop’s AP. What I found was an RF war zone. I wish I would have been smart and taken a screen capture, because this place had all the makings of an unusable hot WiFi mess. Plenty of APs on every 2.4 GHz channel, no 5 GHz APs and a mish-mash of different vendors providing the coverage (Vivato and Aruba, to be specific). Since I was using the Windows 7 wireless client (what can I say, I’m too cheap to spend the fifty bucks on the Juniper Odyssey Access Client) I had no idea which BSSID was mine. I had to sift through a number of APs on channel 11 until I finally found my station’s MAC address. (And if you’re wondering why I didn’t have my laptop named in OmniPeek already, that’s a good question. The reason is that my Macbook Air suffered yet another meltdown and had to be rebuilt. I got all of the requisite sniffing software installed on the Windows partition, but I had yet to repopulate the Name Table.)

Once I found my BSSID, I quickly created a filter for it and started working. I checked the full stats for the AP (about 120 kbps, on average) and then I modified the filter to check to downlink (~74 kbps) and uplink (~46 kbps) usage. Unfortunately, I was there for a job outside of sniffing, so I lacked the time to do a full analysis of the WLAN. Had I been there for strictly sniffing purposes, I would’ve looked more closely at other stations (there were tons, but I didn’t get a full count), Retry percentages and data rates.

The whole experience was an eye opener in one way and quite typical in another way. On the one hand the MGM Grand Garden Arena had a multi-vendor environment with a ton of APs and no 5 GHz coverage, yet it worked. On the other hand, questionable RF design often does work just fine when WLAN usage is fair-to-middlin’, but breaks down when put under stress. This event had one of the smaller media attendances in recent years for a Las Vegas UFC show. I’ll be interested to see what the results look like next time when WiFi usage is likely to be much higher.

Written by sniffwifi

January 20, 2011 at 4:05 am

Posted in Uncategorized

Setting Data Rates – Just (Don’t) Do It.

with 3 comments

A common conundrum for enterprise WLAN administrators is guest access. You often want or need to provide it, but you want to make sure the guest WiFi has a minimal effect on the internal network. One way that people try to limit guest access is by specifying low speeds, but that is a bad idea that usually causes the internal WiFi to be worse off than it should be.

I was doing some work at a hotel in the Chicagoland area recently when I came upon another example of bad guest WiFi. Bad guest WiFi is quite common, but this one was avoidable. I’ve seen bad guest WiFi because of under-covered areas and because of over-covered areas. I’ve seen some guest WLANs with ¬†over-saturation of stations and others with under-saturation of broadband.

As with any WiFi design, there is a little bit of art in the science. You have to look at numbers like signal-to-noise ratio and users-per-channel but in the spaces where desired numbers collide, the owner of the WLAN has to make good choices in allocating the resources that are available.

One of the obvious choices admins often make is to limit the bandwidth available to guest users. ‘Tis a noble idea, but it must be done the right way. Appliances that limit the wired bandwidth of guest users do the job, at least to some degree. (I’ll save my treatise on my distaste for bandwidth limits for another time.) Unfortunately, most WiFi controllers and APs lack true a bandwidth limiting function.

What controllers and APs often do have is the ability to limit data rates. You can dictate that users associated to the guest SSID are limited to either an exact data rate — such as the 18 Mbps that I saw at the hotel near Chicago — or a maximum data rate. In theory this may sound smart, but in reality it is a bad idea because you are limiting data rates, not throughput.

Data rates are the speed of one frame across one data link. If you are using WiFi, that means the speed of one frame from your AP to your laptop. The frames that are being sent are also part of a shared channel. That means that when the AP is sending a frame to your laptop, it can’t be sending a frame to anyone else’s laptop.

Throughput is a measurement of the total amount of data divided by the total amount of time it took to send or receive that data. It is the real, usable speed that your applications have available when you are on a WiFi network.

Your throughput is affected by your data rate, but it is also affected by the data rate of everyone else who is on the same channel. If you are receiving frames at 216 Mbps (as I was when I began writing this piece), that’s great. Your laptop will be taking very little time to receive frames and the other stations on the channel will be very happy that your laptop takes up so little channel time. If someone else on my channel is forced to receive frames at 18 Mbps because they are on a guest SSID, my laptop’s throughput will be compromised because I’ll be staying quiet for more time than I need to while that guest user receives their slow frames.

Manipulating data rates can have other negative effects besides just slowing down the channel. For most WLAN controllers and APs, setting a specific rate limits the speed of frames transmitted by APs, but not transmitted by stations. Here’s a look at a Beacon frame transmitted by my Linksys WRT160N 2.4 GHz 802.11n wireless router:

The rate information (Supported Rates and Extended Supported Rates) is identical to the rate information that was showing up in the Beacon frames at the hotel I was staying at outside of Chicago. Notice how there is no indication that only a 18 Mbps rate will be used by the AP. Stations are receiving Beacon frames that show all rates between 1 Mbps and 54 Mbps as supported. The end result of this is high Retry percentages because stations remain associated to the AP when they are transmitting all the way down to 1 Mbps (where frames can be demodulated at a great distance), but the AP keeps its rates at 18 Mbps (where frames can be demodulated only at a lesser distance) no matter what.

Hopefully I’ve made a convincing argument against specifying low rates for guest access, but there is one other rate-related topic that I want to touch on. It is the topic of disabling low rates in an attempt to enhance roaming quality.

I bring up this last topic because I was teaching a class a while back and one of the students told me that he was told that disabling 1, 2 and 5.5 Mbps was recommended to enhance roaming. The theory is that when a station reaches the lowest rate above the disabled rates (6 Mbps, in this case), the station will know to being the reassociation process, thus avoiding the problem of having stations associated to APs where the signal quality is so poor that only the lowest of the low rates are available.

I am torn on this subject. On one hand, I would assume that whoever told him to disable those low rates had tested the WLAN using the production clients and found that they roamed better with those rates disabled. I am believe that if you test something and it improves performance you should use it, so in that way I like it. On the other hand, this makes little sense to me. In my experience stations tend to begin the reassociation process based on having a low signal strength or signal-to-noise ratio (SNR), not necessarily a low data rate. If a station is receiving frames at a signal level that is above its roaming threshold, then the possibility exists that the station would remain associated to the AP but be unable to demodulate frames because the low rates that could be demodulated have been disabled. The end result of that would be high Retry percentages, and I have seen many WLANs with low rates disabled and high Retry percentages.

Now, I do want to make clear that if you are working with only 802.11g/n stations, then disabling *all* 802.11b data rates (1, 2, 5.5 and 11 Mbps) is advisable in many cases. What I am skeptical of is the idea of disabling *some* 802.11b data rates and leaving others enabled because some 802.11b stations are present on the network.

As always, I’m interested in other peoples’ experience. If you have specified data rates or disabled low rates and found improved performance, please do share with us in the comments section. But my experience has been that doing those things is counter-productive, so my general recommendation is to just leave the data rates alone when configuring your WLAN.

Written by sniffwifi

January 1, 2011 at 12:00 am

Posted in Uncategorized