I tested Guard 3.0 in our Syracuse University Real-World Labs®. The setup was simple. I powered on the rack-mountable server appliance and accessed the Java Web management console after configuring a few parameters using the command-line interface. The server runs on a customized version of Red Hat Linux and uses PostgreSQL to store information fed to it over Ethernet from the wireless sensors.
I also had to install Java Runtime Environment (JRE) 1.4.1 Java HotSpot Client Virtual Machine (free from Sun Microsystems).
Guard comes with two wireless sensors that run an embedded Linux OS and include Cisco Systems' Aironet 350 and Ethernet interfaces. Determining the appropriate number of sensors required for complete coverage and their optimum location in your facility requires time and effort. AirDefense estimates that a sensor typically covers a 1,000-foot radius, but I could test it only up to 170 feet due to the lab building's physical constraints. Because the sensors are passive scanning devices, they have greater effective range than typical access points. AirDefense estimates a ratio of three to five APs per sensor to provide full overlapping coverage.
I connected to the Guard server via the Web management console and found it slow to load--typical of many Java applications. The initial interface uses the dashboard metaphor and provides a summary of the wireless system based on information aggregated from the sensors (see screen at right). I created individual accounts with guest and administrative privileges and used the admin account to change policies and edit various parameters. The guest account was handy for providing view-only access to people in the lab who were intrigued by the system's capabilities. Because I hadn't entered all the lab's wireless devices into the system's database, Guard generated alarms for all unauthorized APs it discovered through passive scanning of all 802.11 channels.