The product has an outstanding GUI and covers a breadth and depth of 802.11-specific problem areas for maintaining a dispersed WLAN. A tedious sensor-rollout method, a lack of an integral reporting mechanism and some other rough edges concern us, but overall this is a very good product.

AirMagnet could make a fair claim to being a leader in wireless LAN analysers. We reviewed the Laptop version in March, but a new version of its distributed edition (announced in March) is now available.

AirMagnet Distributed uses a combination of proprietary access points and notebook-based sensors to help assess an 802.11 a, b or g area. Version 4.0 seems to have solved some of the access point problems we found in an earlier version.

About the system
AirMagnet Distributed is a serious enterprise wireless LAN management system (you can get quite a long way with free tools - see our feature - but don't confuse them with a full monitoring system). It includes four components:

  • a management server that includes its own HTTP server (AirMagnet recommends dedicating a machine to it),
  • one or more sensors (which look like access points),
  • the distributed console (a Windows-only application that organises information from the AirMagnet server application)
  • the reporting system.
.

Unlike some other systems, the AirMagnet Distributed system does not triangulate wireless equipment. Rather, distributed access point sensors are deployed across the network and can be delineated by floor, building and campus to articulate the physical location of errors or problems.

The system did a fine job of giving us wireless information, with only a few minor problems. Like the other AirMagnet products, the distributed system is a wireless-only analysis product. It won't cover wireline problems without assistance from products such as wired protocol analysers or intrusion-detection system applications.

Each sensor had to be configured individually, because each one comes from the factory with the same IP address. Each sensor covers all three 802.11 radio modes (a, b and g). It was easier to use the serial interface on the sensor to update addresses instead of configuring through the Web interface.

The optional reporting software runs on a Microsoft SQL Server database (you may need to get a runtime licence), and organises the huge amount of data that the sensors can generate.

The sensors have to find the Distributed Network Management Server through a private network or through an Internet VPN, to monitor a remote building. Once configured, each sensor gets a software update from the management server if needed. Even on a wireless network filled with problems, the amount of data sent to the management server remains low, about a few thousand bytes per minute, per sensor.

Monitoring produces data in two categories: security and performance. The default settings indicate a "worry about everything" attitude, which we liked as a baseline.

Test it every which way
We used four sensors in our tests, in two different situations: 4,000 square feet on a one-floor building, and a five-story building, also measuring 4,000 square feet.

We tested the sensors in a local and VPN-emulated environment, using a wireless LAN consisting of many different types of 802.11b, a/b, a, and a/g/b access points. Vendors included Intel, D-Link, Linksys, Apple, 3Com, NetGear, Proxim, Buffalo, SMC Networks, Hewlett-Packard and others.

We put the Distributed Management Server on a Compaq SR1020NX generic desktop machine (2.4-GHz Celeron, 1 Gbyte RAM, Gigabit Ethernet, Windows XP Professional, which was connected to a wireline Gigabit Ethernet network. This was in turn connected through an emulated VPN (two Windows 2003 Enterprise Servers) to another Gigabit Ethernet network.

Each wireless network used its own Service Set Identifiers. A Linux machine (Compaq DL360 with two 733-MHz CPUs) was used for Lightweight Directory Access Protocol (LDAP) authentication and RADIUS services. Microsoft SQL Server 2000 ran on the 'local LAN' Windows 2003 Enterprise Server. All software and firmware for all devices, operating systems, hardware, access points, client WLAN cards, and all drivers were updated to current as of May 1, 2004.

We used numerous client notebooks, including two Compaq Presario notebooks, an IBM ThinkPad 600, two Apple G4 notebooks, three desktops with either Linksys or Microsoft 802.11b USB-WLAN devices, two HP NC4000 notebooks, and a Compaq Armada 7380DMT. These machines used a wide variety of WLAN cards from the same list of access point vendors (with the addition of Microsoft).

We modified three Proxim/Orinoco Gold cards to perform association denial-of-service tests by introducing a small switch into their circuitry to make them transmit, but not receive

A deluge of information
Alerts can be sent by e-mail, SMS, telephone, sounds and instant messaging. We tested all the alerts except instant messaging.

The default settings produced an immediate deluge of information and alarms - even if a network is correctly configured for its feature set. Some of the information is trivial, such as the detection of an 802.11g access point that does not support smooth 802.11b-to-g transition. Many older access points don't do this, and even firmware updates won't help. It's possible to remove the detection of items such as this, so your logs don't fill up with essentially useless information.

The challenge with the system then is to find baselines and "normal" settings for a monitored network. Fortunately, the management console GUI is divided into a monitoring GUI and a policy/management GUI that gives highly articulate, though occasionally ambiguous, settings information about each possible monitoring attribute and condition. Understanding the settings requires in-depth knowledge of how 802.11-based networks function. The ambiguity arises as some settings don't have good default values, because networks are so different.

For example, it is a good idea to watch for access points that go offline. It means there is a possibility that an area is not served, because an access point is unavailable, it is rebooting, or it was nefariously substituted. There are many reasons that an access point goes offline, from power problems to people or objects interfering with the sensor's ability to detect a signal. For this reason, sensors need to be placed where they are unlikely to be blocked, to reduce false positives. This requires some fine tuning and periodic adjustment.

Picks up most security problems
The system can find many security problems. Our testing verified problems such as broadcasting a Service Set Identifier (SSID), the lack of Wired Equivalent Privacy, rogue access points (in 802.11a, b and g), ad hoc association attempts, session hijacking attempts, open authentication attempts and VPN verification. We tried Point-to-Point Tunneling Protocol, Secure Shell and IPSec; Layer 2 Tunneling Protocol is supported but we used IPSec over L2TP and L2TP was undetected (see this feature for more on VPN protocols). .

We also verified man-in-the-middle detection, six brands of access points for default configurations (D-Link, Linksys, Netgear, Proxim, 3Com and Buffalo), and an off-hour activity check. The off-hour check defaults are not monitored by time of day, but rather by SSID for local WLANs, neighbouring WLANs and guest WLANs. We consider this a weak feature. Fortress encryption detection and monitoring is supported, but we chose not to test this.

The system also can detect 802.1x (authentication that uses RADIUS - see this feature for more information). We configured a Linux machine with Lightweight Directory Access Protocol (LDAP) and RADIUS, and the Temporal Key Integrity Protocol (TKIP) as used in the Wi-Fi Protected Access (WPA) specification - see this feature for more. The authentication server, running through a 3Com and Linksys access point, authenticated clients correctly. We configured the keys, which should change periodically, to never change - thus defeating TKIP. AirMagnet could not detect this, which is ostensibly monitored in a measured field called "802.1x rekey timeout too long."

Other attacks, such as a denial-of-service attack, including association and authentication floods, all were detected correctly.

Performance measurement
The system also could detect deployment/operations errors, 802.11a/b/g errors and inter-protocol usage errors between 802.11b and g, radio frequency management problems and "problematic traffic patterns." The system's frequency calibration was a bit off, which we verified with an oscilloscope and external time-base trigger. The system sometimes reports off-channel errors that aren't accurate, but the missed channel information was always close.

The system also found hidden stations - clients that can't hear other nodes and therefore collide with them by broadcasting over them. We used shielding to partition stations electrically and found that if the sensors could find them, they could determine whether the stations were colliding frequently (because they were hidden from other stations' signals). The cure for this was to either move the access point that the node should associate with, or re-orient the client so it could detect other signals. This problem often happens when a node/machine sits on a desk near a steel filing cabinet or other wireless obstruction.

The system occasionally found high noise on a channel when a sensor was in close physical proximity to an access point. The sensors should be kept at least 9 feet from any client or access point, or false positives could be triggered. We made several adjustments to this threshold.

Documentation is relegated to a thin user's guide, and replaced by extensive and usually articulate on-screen help and prompts. In the management policy settings area, a wizard was helpful and somewhat complete, although it required a good base knowledge of WLANs.

Reporter - beautiful but pricey
We were disappointed by the lack of an integrated report generator. Query-based, printed reports through the use of the management console are available as a separate, pricey option (the Reporter application which costs £1730). It is possible to use PrtScrn to dump reports to a printer without Reporter (as well as export lots of data), but we would have preferred an integrated report generator. When added, Reporter uses SQL Server, which adds administrative overhead. On the plus side, Reporter installation after a SQL Server install was simple.

Another upside is that the reports are beautiful, simple to put together, and contain easy-to-understand information for the technically inclined, and for companies that require an audit trail. Without the Reporter system, AirMagnet Distributed is a lesser product.

Bottom line
AirMagnet Distributed excels in its GUI, in its deep knowledge of 802.11-specific problems it can solve, and in the overall ease of use to maintain a disperse WLAN. We liked its nervousness on the default settings, despite some inevitable fine-tuning of the alerts.

It does take a bit of work to deploy a fleet of sensors - both the initial configuration and deployment. Our biggest concern remains a lack of an integrated reporting system.

Tim Henderson is managing director and principal researcher for ExtremeLabs.

OUR VERDICT

Any corporate wireless LAN needs monitoring for security and performance, and this is a good product to do that with. You will need to know a fair amount about wireless LANs to set it up, but then you should anyway to run a corporate wireless network.