لطفا منتظر باشید ...
Hack 34 Historical Link State Monitoring
Comprehensively track the performance of your
wireless links over time.
The monitoring tools
mentioned so far give you a good instantaneous reading of received
signal and noise levels for a given radio link. While useful for
proving a link and installing your gear, remember that radio
conditions change over time. Doing the occasional
"spot check"
doesn''t really give you the full picture of what is
going on.
For example, take a look at Figure 3-31. This displays radio data for a one-mile link,
averaged over several days. You can see that in the middle of each
day, the signal drops by as much as 6 dB, while the noise remains
steady (remember that these are really negative numbers, so in this
graph, a smaller number is better for signal). The repeating pattern
we see indicates the effect of thermal
fade. This particular link is a simple
waveguide antenna mounted in the middle of a low sloping roof. As the
roof (and the rest of the environment) heats up, the perceived signal
is apparently less. At night, when things cool down, the perceived
signal increases. The effect of thermal fade in this installation was
later mitigated (by about 2 or 3 dB) by relocating the antenna,
placing it closer to the edge of the roof. With less hot roof in the
path, the effect of the day''s heat was reduced.
Nothing can completely eliminate the effects of the sun on a long
distance path, but without a historical graph, it would be difficult
to account for the effect at all.
Figure 3-31. This link shows a good deal of thermal fade in the middle of the day.
Figure 3-32
shows another interesting
artifact, this time averaged over several weeks.
This link is about a mile-and-a-half
long, and still shows some of the effects of thermal fade. But look
at the noise readings. They are all over the map, reading as high as
-89 and jumping to well below -100. This most likely indicates the
presence of other 2.4 GHz devices somewhere in the path between the
two points. Since the noise remains steady for some time and then
changes rapidly to another level, it is probably a device that uses
channels rather than a frequency-hopping device. Given the wide
variety of perceived noise, I would guess that the most likely
culprit is a high-powered 2.4 GHz phone somewhere nearby. It is
probably impossible to ever know for sure, but this data might
warrant changing the radio to a different channel.
Figure 3-32. A link with a noisy environment.
These graphs were generated using Linux
and some freely available tools. A modest
Linux server can monitor a
large number of radio devices, and the requirements on each of the
APs is quite small. I will assume that you are using a DIY AP running
Linux
[Hack #51], although similar
techniques can be used for just about any kind of radio device.
You can monitor signal strength using any available TCP port above
1024 on the APs. Port 10000 is usually a good candidate. On each of
the APs to be monitored, as well as on the machine doing the
monitoring, add lines like these to
/etc/services:
mon0 10000/tcp
mon1 10001/tcp
mon2 10002/tcp
Then add a line like this to the
/etc/inetd.conf on the monitored machines:
mon0 stream tcp nowait nobody /usr/local/bin/iwconfig iwconfig eth1
Be sure to use the path to iwconfig for your
system, and specify the device to be monitored at the end. You can
add as many iwconfig lines as you like, using a
different port each time:
mon1 stream tcp nowait nobody /usr/local/bin/iwconfig iwconfig wlan0
If you need more ports, add more lines to your
/etc/services. When all of your radio cards are
set up, restart inetd. You can verify that the
changes have taken effect by using telnet:
pebble:~# telnet localhost mon0
Trying 127.0.0.1...
Connected to localhost.
Escape character is ''^]''.
eth1 IEEE 802.11-DS ESSID:"NoCat" Nickname:"pebble"
Mode:Managed Frequency:2.457GHz Access Point: 00:02:2D:1C:BC:CF
Bit Rate:11Mb/s Tx-Power=15 dBm Sensitivity:1/3
Retry limit:4 RTS thr:off Fragment thr:off
Power Management:off
Link Quality:14/92 Signal level:-83 dBm Noise level:-96 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:6176330
Tx excessive retries:7880 Invalid misc:0 Missed beacon:0
Connection closed by foreign host.
pebble:~#
To collect the radio data, you need
netcat installed on the machine that does the
collection. netcat is a free and insanely useful
utility available at http://www.atstake.com/research/tools/network_utilities/.
Think of it as a scriptable telnet program that will handle just
about any kind of network data you want to throw at it. I use
nc to connect to each of the machines, and
scrape the results with a Perl script.
With the
nc binary installed on your system, use this
wrapper to collect the data:
#!/usr/bin/perl -w
use strict;
my $ip = shift;
my $port = shift;
($ip && $port) || die "Usage: $0 ip port\n";
open(NC, "nc $ip $port |") || die "Couldn''t spawn nc: $!\n";
while(<NC>) {
if(/Signal level:-?(\d+).*Noise level:-?(\d+)/) {
print "$1 $2\n";
exit;
}
}
die "Warning: couldn''t find signal and noise!\n";
I call it /usr/local/sbin/radio.pl, and invoke
it with the IP address and port number on the command line. It simply
returns two unsigned numbers representing the current signal and
noise readings:
rob@florian:~$ radio.pl 10.15.6.1 mon0
83 96
rob@florian:~$
In case you haven''t recognized it already, the tool
that actually stores the data and draws the pretty graphs is
Tobi Oetiker''s
excellent rrdtool. Like many powerful tools,
rrdtool can be imposing at first (sometimes to
the point of frustration). Efficient data collection and accurate
visual presentation isn''t as simple as you might
think. Of course, rrdtool will handle just about
any data type you track, but getting it working can be tricky the
first time.
Personally, I prefer to use a tool like Cacti
(http://www.raxnet.net/products/cacti/) to
manage my rrdtool graphs for me. It is simple to
install, has an easy to use web interface, and does the dirty work of
managing your rrdtool databases. With Cacti
installed, simply set up radio.pl as a data
input script, and create a data source for each radio to be
monitored. See the Cacti documentation for more details.
When properly configured, Cacti automatically generates Daily,
Weekly, Monthly, and Yearly averages for all of your data sources.
If you prefer to roll your own rrdtool, then use
a command like this to create your database:
/usr/local/rrdtool/bin
/rrdtool create /home/rob/radio/radio.rrd --step 300 DS:
signal:GAUGE:600:0:150 DS:noise:GAUGE:600:0:
150 RRA:AVERAGE:0.5:1:600 RRA:AVERAGE:0.5:6:
700 RRA:AVERAGE:0.5:24:775 RRA:AVERAGE:0.
5:288:797 RRA:MAX:0.5:1:600 RRA:MAX:0.5:6:700
RRA:MAX:0.5:24:775 RRA:MAX:0.5:288:797
Be sure that the rrdtool binary is in your PATH,
and change the print "$1 $2\n";
line in radio.pl to something like the
following:
`rrdtool update /home/rob/radio/radio.rrd --template signal:noise N:$1:$2`;
Add a call to radio.pl to a cron job that runs
every five minutes or so to regularly collect the data:
*/5 * * * * /usr/local/sbin/radio.pl 10.15.6.1 mon0
Finally, once you have collected some
data, you can generate a graph like Figure 3-32 with
this command:
/usr/local/rrdtool/bin/rrdtool graph -
--imgformat=PNG --start="-604800"
--title=" Radio" --rigid --base=1000 --height=120
--width=500 --upper-limit=105 --lower-limit=60
--vertical-label="dBm" DEF:a="/home/rob/radio/ radio.rrd":signal:AVERAGE DEF:b="/home
/rob/radio/ radio.rrd":noise:AVERAGE AREA:a#74C366:"Signal"
LINE1:b#FF0000:"Noise"
> graph.png
While the other tools mentioned in this chapter will give you a good
instantaneous estimate of how well your link is doing,
rrdtool, netcat, and this
simple script will give you impressive historical data that can be
invaluable for troubleshooting your network. In addition to signal
and noise, rrdtool can also track uptime,
network traffic, associated clients, transmission errors, and any
other data you can think of. The reward of having clear historical
graphs is well worth learning to deal with the complexity of
rrdtool.
