Bad Medicine: Roaming and Sniffers

I believe in sniffers. I believe in planning for client roaming. And I believe that mixing the two is a bad idea. Using a sniffer the right way and planning for client roaming the right way are both essential for having a high quality WiFi network, but it's a good idea to keep the two separate.

This is, of course, a blog about WiFi sniffing, but to understand why using sniffers to plan for roaming is trouble, let's go into some background on WiFi client roaming.

WiFi (802.11) networks were designed like cell phone networks in that client stations would be able to maintain application connectivity while moving between access points. They were also designed to be unlike cell phone networks in that the client station would control when roaming happens. You see, in cell phone networks, the network infrastructure controls when your phone moves to a different base station. That design makes sense because cell phones have a built in way of giving base stations information about the phone's RF environment. A good roaming decision requires accurate RF information procured at the location of the mobile device (since RF is location-specific, after all), so this ability of cell phones and base stations to communicate makes it so that the infrastructure can make a good decision on when a phone should handoff. WiFi networks (at least, prior to 802.11k) lack that ability. Only the client knows its RF environment, so only the client can determine when roaming should occur.

Let's think about the impact of having a client that decides when it is going to roam. One thing that means is that we lose the ability to do a fully offline site survey. I can't just upload a floorplan, plot out APs and configure a signal level or signal-to-noise ratio (SNR) at which clients will look for a new AP. I have to test each client individually and figure out approximately what signal/SNR will cause each type of client to engage in roaming. (It actually gets even more complicated than that, as sometimes a client will react differently to two different APs that produce the exact same signal.)

There is a way to plan for roaming. In broad strokes, the steps are:

  1. Find the signal/SNR at which your station typically initiates reassociation. This is the client station's roaming threshold.
  2. Run a site survey planning application (AirMagnet Survey/Planner being my tool of choice). When you do this, your goal is to plot out an AP's theoretical coverage area and find the areas where client stations are are likely to hit their roaming threshold. Then you want to make sure that a different AP will also cover that area at an even higher signal so that roaming will (hopefully) be smooth.
  3. Verify your AP locations by going on site and surveying to see if you get the signal/SNR levels (or, at least something close) that showed up in your plan. You can do this by temporarily mounting APs and recording their signal/SNR levels.
The planning application and the on-site surveying are best left for another time (or, perhaps, another blog). My concern is with testing the client station to determine its roaming threshold.

If you're sniffer-friendly, the temptation may be to try to find the roaming threshold by looking at a packet capture. The idea is that you'd plug in a WUSB600N (for WildPackets OmniPeek), a DWA-160 (for AirMagnet WiFi Analyzer) or an AirPcap NX (for my frenemy, Wireshark) and run your packet capture while moving between two test APs. Any one of the aforementioned sniffers will capture your reassociation request/response frames when you roam. Once you find that reassociation response frame (which always is transmitted by the AP), you look at its signal level and, voila, you have a roaming threshold. 

The problem with using your sniffer to find the roaming threshold is that the reassociation response frame you'd be looking at would be showing a received signal strength as read by the capture adapter. The client station's radio would not be showing you its received signal strength. Due to differing receive sensitivities, antenna gains or radio/antenna connections, the signal strength shown in a reassociation response frame could be quite different than the actual received signal strength at your client.

There is a better way to identify the client station's roaming threshold, and that is to view the signal strength from the client utility. And if you have a client utility that doesn't show you a signal strength as a dBm or % reading, you can use some other utility that ties into the client station's radio (Metageek inSSIDer, the Xirrus WiFi Monitor and the netsh WLAN commands are all free tools that are useful for Windows-based clients). This can be tricky because you really have to keep your eye on your BSSID to see exactly when the client station reassociates, but if you run through a few tests you'll get the hang of it. Once you do, you'll have a good idea what level of roaming threshold you should plan for.

Client roaming is one of the toughest WiFi problems around. WiFi sniffers are often the best tools for solving tough wireless problems. Unfortunately, in they don't go well together. WiFi sniffers are great if you need to identify, test or solve roaming problems after an installation, but those applications should be set aside during the planning stage.


Comments

  1. Ben,
    What about using Airmagnet/MetaGeek/AirPCap with multiple adapters? Isn't that a solution to the roaming problem?

    ReplyDelete
  2. Luis: Thank you

    Tom: That fails to solve the fundamental problem. It doesn't matter if you *capture* on 27 channels. The problem is capturing. You don't want to capture. When you capture you don't get an accurate signal strength reading because you're in a different location than the associated WiFi radio.

    ReplyDelete
  3. I though it's all about medicine but anyway, I liked what I read about wifi thing.
    4rx

    ReplyDelete
  4. Oops. I also thought it's all about medicine. Now, it's really true that Title plays an important role in SEO. Great job.

    generic viagra

    ReplyDelete

Post a Comment

Popular posts from this blog

Five Facts About 6 GHz Wi-Fi

Chips, Glorious Wi-Fi 6E Chips!

Go To Sleep, Go To Sleep, Go To Sleep Little iPhone