|
|
|
|
Sneak an AiroPeek at WLAN Stats
|
 |
|
May 27, 2002
By Peter Morrissey and Dilip Advani
>> continued from previous page
|
|
|
Executive Summary: Wireless LAN Analyzers
|
|
|
WLANs may be the wave of the future, but right now they bring to mind the bad old days of shared Ethernet--without the natural boundaries provided by wires. Collisions can occur, slowing down the network, and though there are distance limitations, you can't control where packets will end up. Heck, you can't even keep people from deploying unsecured wireless access points. You can, however, use a wireless analyzer to track down those rogue access points (what you do to the wretches who set them up is between you and your legal department) and determine your WLAN boundaries. Wireless analyzers can deliver detailed packet summaries and keep you informed about your network's health and safety by reporting whether WEP is enabled, if default SSIDs are in use, the biggest bandwidth users, your actual throughput rate and much more.
We tested Network Associates' Sniffer Wireless, Network Instruments' Expert Observer and WildPackets' AiroPeek NX, and were impressed by all of them (though Sniffer Wireless' premium pricing gave us heartburn). After extensive tests--some involving microwave ovens--in our Syracuse University Real-World Labs®, we gave our Editor's Choice award to WildPackets' AiroPeek for its all-around ease of use and solid monitoring. The expert view in Sniffer Wireless shined in its ability to detect rogue access points. And Network Instruments' maiden effort in this market, the Expert Observer, displayed impressive reporting at such a bargain price we gave it our Best Value award.
|
|
How We Tested Interference
|
|
|
We set up numerous wireless access points from a variety of vendors in our Syracuse University Real-World Labs®. Some represented "production" access points; others represented "rogue" access points that users might introduce without notifying IT (see the diagram below).
We had fun testing interference from other sources of 2.4-GHz transmissions--namely a 2.4-GHz Panasonic cordless phone, a microwave oven and several Bluetooth devices. Although the results weren't consistent enough to let us rate the analyzers' abilities to detect problems, the interference was significant.
For the Bluetooth interference test, we had two laptops, each with a Bluetooth card, exchange files next to the 802.11b equipment, which was involved in downloading a file wirelessly from a server. We noticed a lot of CRC errors and wireless retries on the 802.11b file download. The number of errors decreased as the distance between the Bluetooth and the 802.11b equipment increased.
For the microwave, we saw similar, though fewer, errors. We could not judge the phone interference because we got different results at different times. Sometimes, a file transfer would just stop and the wireless client would lose association with the access point; other times, the 802.11b equipment functioned normally. The different results probably occurred because the phone was switching channels. The one thing we could conclude is that interference from other 2.4-GHz signals is real and unpredictable.
|
|
NetStumbler: Network Busybody
|
|
|
NetStumbler snags information about wireless access points, including MAC addresses, SSIDs, channels used, real-time signal and noise information, and WEP use. It is popular among "war drivers"--people who cruise around with their laptops, identifying open wireless networks in the same way that "war dialers" dial long lists of phone numbers to identify an open modem. NetStumbler also helps network administrators shield corporate data from these drive-by hackers by pinpointing rogue access points and auditing legit access points.
We tested NetStumbler using eight access points and wireless residential gateways. First, we set the client cards' SSIDs to "any." As a result, the access points answered NetStumbler's probe requests with their correct SSIDs. Most access points will do this by default, negating the usefulness of the SSID. Important lesson: With SSIDs, "any" is bad. Keep war drivers from using NetStumbler to detect SSIDs by reconfiguring your access points so they don't respond to probe requests unless the client has the correct SSID configured. We used a Cisco 340 access point set to stop responding to client probe requests unless the client had the correct SSID, preventing NetStumbler from discovering our SSIDs.
NetStumbler also will help you determine an access point's location, using a GPS device to mark locations. We connected a Garmin GPS II device to our laptop's serial port and took NetStumbler outside (the GPS device needs a clear and unobstructed view of the sky for best performance and needs time to compute fixed locations). The GPS helped us pinpoint our location's coordinates (43.03 north latitude and 76.13 west longitude), and we combined that information with the details of the accessible access points NetStumbler discovered. Using a new Windows-based software program, StumbVerter, we imported the NetStumbler files into Microsoft's MapPoint 2002 and pinpointed the access points' locations along with the NetStumbler information.
NetStumbler is great for sniffing out access points and wireless gateways and can do low-level site surveying, but wireless analyzers serve the more important purposes of wireless monitoring, troubleshooting, wireless packet decoding, checking for interference and more detailed security assessments. For example, NetStumbler cannot capture and decode packets, and it cannot monitor utilization. It also cannot tell you if other types of encryption, like IPsec, are in use.
--Dilip Advani
|
|
|
|
|
