Monitoring Wi-Fi access points: what the controller page does not tell you

Most access points come with a pretty page. A controller, a phone app or the router's web interface shows a list of APs, a green dot next to each one, a client count and sometimes a health score. That page is fine for answering "is it on". It is poor at answering why the back bedroom drops video calls at nine in the evening, because it shows the present, rolls everything into a score, and keeps little or no history.

What follows is the checklist I work through when I put access points under real monitoring, at home or in a small office. It starts at the cable, because that is where a surprising number of Wi-Fi complaints really live, and it ends with a cheap trick that measures the network from a client's point of view. Nothing here needs a paid tool.

The wire and the power

1. Negotiated link speed on the switch port

An AP that should link at 1 Gbit/s and shows 100 Mbit/s nearly always has a cabling fault. Gigabit Ethernet over copper uses all four pairs; 100 Mbit/s gets by on two. One damaged pair, from a run crushed behind a baseboard or a sloppy punch-down on a keystone, and the link quietly falls back. The AP still works, the dot stays green, and every client on it now shares 100 Mbit/s. Poll ifHighSpeed on the switch port (it reports 1000 or 100) and alert when it changes. As an electrician I will add: re-terminate before you replace the cable. It is usually the last inch.

2. Errors on that port

Rising input errors on the AP's switch port point the same way as a speed drop: a bad patch lead, a poor termination, a data cable strapped tight to a power run. Graph the error counter as a rate, not a total. The interface counters article explains which counters to read.

3. PoE allocation and budget

If the switch powers the AP, it can usually report per-port draw and the total budget in use. Two things go wrong. The switch runs out of budget and refuses power to whatever was plugged in last, or an AP gets less power than it asks for and starts in a reduced mode, with a radio or some antennas switched off, mentioning it only in its own log. Compare the port's allocation with the figure on the AP's datasheet. For reference, an 802.3af port supplies up to 15.4 W and an 802.3at port up to 30 W at the switch. The PoE budget calculator is handy when you are deciding whether a small switch can carry three APs and a camera.

4. Reboots

sysUpTime (1.3.6.1.2.1.1.3.0) dropping back toward zero means the AP restarted. Strictly it is the SNMP agent's uptime, so an agent restart looks the same, but either way it is worth a look. An AP that reboots every few days usually has a power problem (marginal PoE, a tired injector) or a firmware crash, and nobody notices because it is back in two minutes. Alert on any reboot you did not schedule.

The box itself

5. CPU, memory and temperature, where the AP exposes them

An AP in a hot attic or a ceiling void above a kitchen runs warm all summer. I graph these three but only alert on temperature. CPU spikes on a small AP are common and rarely mean anything on their own.

The radio

6. Channel and width, recorded over time

Many controllers change channels automatically. Record which channel and width each radio was on, so when someone says calls dropped at 21:00 you can see whether the AP had just jumped. On 2.4 GHz in the US, stay on 1, 6 or 11 at 20 MHz wide. Those three are the set that does not overlap.

7. Radar events on 5 GHz

Several 5 GHz channels are shared with radar systems, under rules known as DFS. An AP on one of those channels must listen before it transmits (about a minute on most of them), and if it detects radar it must leave the channel and stay off it for at least 30 minutes. Every client on that radio sees a drop and a reconnect. Near some airports and weather radars this happens often. If your logs show radar events, move to a non-DFS channel (36 to 48 or 149 to 165 in the US) for a week and see whether the drops stop.

8. Channel utilization

If I could have only one radio number, it would be this: the share of time the radio heard the channel as busy, whether from your own clients, a neighbor's network or non-Wi-Fi noise. In an apartment building the 2.4 GHz band can sit high all evening. My rule of thumb: sustained above about 50 percent, everyone on that channel will feel it. On OpenWrt and other Linux-based APs, the survey data gives you the raw figures:

iw dev wlan0 survey dump

The entry marked as in use shows "channel active time" and "channel busy time". Busy divided by active, sampled every minute, is your utilization.

9. Noise floor

The same survey shows noise in dBm. A quiet channel sits around -90 dBm or lower. A floor that climbs toward -80 dBm eats into every client's signal-to-noise ratio, and the usual suspects are a cheap video sender, an old cordless phone, or a microwave on 2.4 GHz.

10. Retries and failures

Per-client transmit retries and failures are in the station dump:

iw dev wlan0 station dump

Look at "tx retries" and "tx failed" next to "tx packets". A retry share that climbs in the evening and falls at night points at interference or crowding rather than at one bad client.

The clients

11. Signal per client, as a spread and not an average

An average of -60 dBm hides the one laptop in the garden office at -78. Rough guide: -67 dBm or better for calls and video, about -70 is fine for browsing, worse than -75 is trouble. Plot the weakest five clients, not the mean.

12. Data rate per client

A client stuck at a low rate takes much more airtime to move the same data, and airtime is shared. One old tablet in a far corner can slow the whole radio. Watch for sticky clients that stay attached to a distant AP when a closer one is available.

13. Client count and churn per radio

Count matters less than churn. A client that connects and disconnects ten times an hour is either out of range, fighting with a roaming setting, or has a power-saving bug in its driver.

The logs

14. Send AP syslog to a collector

On OpenWrt, remote logging is four commands:

uci set system.@system[0].log_ip='192.168.10.5'
uci set system.@system[0].log_port='514'
uci commit system
/etc/init.d/log restart

Anything that runs hostapd logs association events as lines containing AP-STA-CONNECTED and AP-STA-DISCONNECTED followed by the client's MAC address, and radar hits as DFS-RADAR-DETECTED. Count disconnects per client per hour and the device that drops every few minutes stands out at once. Syslog for small networks covers the collector side, including rotation so the logs do not fill the disk.

From the client's side

15. A probe client in the worst room

Everything above is the AP's view. The cheapest way to see what users see is a Raspberry Pi on Wi-Fi in the room people complain about, running a small script from cron every minute:

#!/bin/sh
# /usr/local/bin/wifi-probe.sh, run every minute from cron
TS=$(date +%s)
SIG=$(iw dev wlan0 link | awk '/signal:/ {print $2}')
RATE=$(iw dev wlan0 link | awk '/tx bitrate:/ {print $3}')
LOSS=$(ping -c 10 -i 0.5 -q 192.168.10.1 | grep -o '[0-9.]*% packet loss' | cut -d% -f1)
echo "$TS signal=$SIG rate=$RATE loss=$LOSS" >> /var/log/wifi-probe.log

Three details make the numbers honest. Unplug the Ethernet cable, or the Pi will happily send everything over the wire. Turn off Wi-Fi power saving with iw dev wlan0 set power_save off, or you will measure the Pi dozing rather than the network. And put the Pi where a laptop would sit, at desk height, not on top of a bookcase near the ceiling. I built mine from the same kit as the one in the Raspberry Pi monitoring weekend build, so it reports into the same graphs.

A week of that log, set against the AP's channel changes and radar events, usually answers the bedroom question by itself.

What I skip

A house or a small office does not need a spectrum analyzer, packet captures of every frame, or a paid heat-mapping tool. A free survey app on a phone and a slow walk through the building tells you where coverage ends. I also do not alert on client counts, CPU or individual weak clients. Those go on a graph you look at when something is already wrong.

If you only set up three things

1. An alert when an AP's switch port changes speed or starts counting errors.
2. AP syslog sent to a collector, with disconnects counted per client.
3. A Pi probe in the room people complain about.

Those three catch the bad cable, the flaky device and the problem only users can see, and together they cost one spare Pi and an afternoon.