Q: I try to compile ap-utils, but it complains that it can't find the menu.h file: [root@server src]# make gcc -O2 -Wall -c -o ap-cnf.o ap-cnf.c ap-cnf.c:24:18: menu.h: No such file or directory make: *** [ap-cnf.o] Error 1 A: You need to install ncurses and ncurses-devel packages from your distro. Or just build and install ncurses libs from sources. Q: I try to compile ap-utils, but the compilation suddenly breaks with the following errors: gcc -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I../lib -I../intl -I.. -g -O2 -Wall -W -c bridge.c bridge.c:46: initializer element is not constant bridge.c:46: (near initialization for `bridge_modes[0]') bridge.c:47: initializer element is not constant bridge.c:47: (near initialization for `bridge_modes[1]') bridge.c:48: initializer element is not constant bridge.c:48: (near initialization for `bridge_modes[2]') bridge.c:49: initializer element is not constant bridge.c:49: (near initialization for `bridge_modes[3]') bridge.c:50: initializer element is not constant bridge.c:50: (near initialization for `bridge_modes[4]') bridge.c:52: initializer element is not constant bridge.c:52: (near initialization for `bridge_modes[5]') A: Your gettext is not up-to-date. You need to either update gettext package for your distro, or you'll need to completely disable NLS support for ap-utils by appending '--disable-nls' to configure. If you do so, the compilation may still end with an error like this: make[2]: Entering directory `/root/work/ap-utils-1.5/po' make[2]: *** No rule to make target `all'. Stop. make[2]: Leaving directory `/root/work/ap-utils-1.5/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/work/ap-utils-1.5' make: *** [all-recursive-am] Error 2 You may safely ignore this one. Q: I bought an access point. Unfortunately, the documentation does not state what are the default community strings defined within the device. Do you know what it is, or where I could find it out? A: It should be in your AP's documentation, really. For example, the default communities for Linksys WAP11 are: "public", "private", "linksys". Most other devices have all three communities predefined to the same value, such as "public", "public", "public". If you just got an AP from someone who didnt provide you with the currently configured community strings, and your AP has no reset button, but has an USB port, you may try to reset AP to its default (manufacturer) configuration using "DFU" utility (in Windows), provided by the manufacturer of your device. *NIX variant of DFU utility is currently in progress and should be available in one of upcomming releases. Q: The wireless & ethernet stats counters are reset to zero each time I grab the KnownAP signal and quality stats. The same issue happens when performing KnownAP scan using the ap-config program without modification. A. This happens because the only way to see updated KnownAPs info is to put your device to the AP-client mode with preferred BSSID 000000000000. Device needs to be rebooted so that this change goes into effect. As side effect of this reboot, all counters in the device are, of course, zeroed. After this, the utility also takes care to reconfigure device back to its previous setting (second reset). Unability to perform KnownAP scan while in different than AP-client mode is generally a feature of all firmware versions for devices with INTERSIL radio. All in all, it is a firmware feature, not a bug. The RSSI and LQ stats may be retrieved without AP reboot (and thus without reset of wireless & ethernet statistics counters) only if the device is permanently set to the AP-client mode. Q: Can someone give me the "newbie" answer to what's the relationship/difference between RSSI and Link Quality? A: RSSI = Received Signal Strength Indication. Measures only the signal amplitude. This plays a major role in calculating the fade margin of the link. The Link Quality value represents how clean the signal is - it reflects eventual degradation of radio signal transmision conditions, such as interference, multipath reflections, etc. This measure plays a major role in determining the data throughput. Low Signal Quality would normally mean frequent retransmissions, dropped packets etc. Note, that firmware for ATMEL-based devices with RFMD radio does not provide Link Quality value (and this is a firmware feature, not a bug). Q: I have an ATMEL-based device with RFMD radio, use the firmware from E-ZY.NET and the graph of RSSI value history looks very jumpy. Is this normal, or is my link really so bad? A: It is normal, you dont need to be afraid. Also this is why 'RSSI average' and 'RSSI rounding' graphs are provided for - they allow you to see the averaged value of the RSSI over certain period of samples. Apparently, the actual RSSI value shown reflects also the signal phase conditions (influenced by signal reflections, and interference). So you may eventually think of it as 'RSSI + LQ aggregated'.