Americas

  • United States
Neal Weinberg
Contributing writer, Foundry

AirMagnet

Opinion
Jun 29, 20043 mins
Network SecurityWi-Fi

* The Reviewmeister tests Version 4.0 of AirMagnet Distributed

Our favorite wireless LAN analyzer from last year now has a distributed version that uses a combination of proprietary access points and notebook-based sensors to help assess an 802.11 a, b or g area.

So the Reviewmeister recently tested Version 4.0 of AirMagnet Distributed, which seems to have solved some of the access point problems we found in an earlier version.

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 Distributed includes four components: a management server that includes its own HTTP server (AirMagnet recommends dedicating a machine to it); a sensor (looks like an access point); the Distributed Console (a Windows-only application that organizes information from the AirMagnet Server application); and the reporting system.

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.

Initial configuration of each sensor was necessary, one at a time, 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 (a runtime license can be obtained if needed), and organizes 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 Internet VPN (anything through a direct route). 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.

The challenge with the system 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 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 the full report, go to: