Monitor a Linux Wireless Interface with wifi-status

Wi-Fi drops mid-call and ip addr shows nothing useful, so you reach for wifi-status to watch everything at once. It is a live dashboard covering link details, addresses, routes, recent kernel messages and basic reachability, all in one place. It is a diagnostic tool, not a network configuration command: it does not join a network, change NetworkManager settings or repair a broken connection.

Allow five minutes for a quick check. This system ships wifi-status as part of Byobu 6.11-0ubuntu1.1. You need a wireless interface, the iw, ip, journalctl and ping commands, and permission to read the current-boot journal. It sends ICMP probes, so only run it on a network where that traffic is fine.

1. Find the interface before starting the monitor

The command takes one optional interface name. Leave it out and the installed script grabs the first interface iw dev prints. Fine on a laptop with one adapter, a coin toss on a host with several radios:

$ iw dev
phy#0
\tInterface wlan0
\t\tifindex 3
\t\ttype managed
$ ip link show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> ...

Replace wlan0 with the interface name your machine reports. A name such as wlp2s0 is normal. If iw dev prints no interface, stop here: the command cannot monitor a wireless device that the kernel has not exposed.

2. Understand what the monitor will display

Before launching it, check the route and address yourself. These commands are read-only:

$ ip addr show dev wlan0
$ ip route show
$ journalctl -b --no-pager -q | grep -i wlan0 | tail -n 10

The installed utility combines similar information into a repeating display. Outside a tmux session it runs a watch view containing wireless information, the interface address, routes, recent current-boot journal lines and a one-packet ping to 8.8.8.8. Inside tmux or Byobu it creates a window named wifi-status with panes for wireless details, addresses, routes, pings, journal output and, when available, traffic speed.

That means the output is a snapshot of several different questions:

• does the kernel see the interface and its wireless state?
• does the interface have an address?
• does the routing table send traffic where you expect?
• do recent current-boot logs show association or driver errors?
• can the host reach the configured route and the public probe address?

3. Start it with an explicit interface

Use the interface as the sole argument. The manpage documents no option flags; an argument such as --help is treated as an interface name, not as a request for help:

$ wifi-status wlan0

In a Byobu or tmux session, look for the new wifi-status window and its panes. In a plain terminal, expect a repeatedly refreshed display. If the screen stays empty, compare the selected interface with iw dev and run the read-only checks from the previous step.

Checkpoint: do not treat a successful launch as proof of Internet access. A wireless association can be healthy while DNS, routing, captive-portal authentication or the remote ping target is unavailable. Read each pane separately.

4. Stop it carefully

Use your terminal's interrupt key, normally Ctrl-C, when you are done. The Ubuntu script installs a shutdown trap that runs pkill -f -9 wifi-status. That is broader than just stopping the foreground process: it can catch any process whose command line happens to contain the string wifi-status.

For that reason, run the utility in a dedicated Byobu or tmux session and do not give unrelated commands names containing wifi-status while it is active. If you need to investigate a stuck session, inspect matching processes before taking action:

$ pgrep -af wifi-status
$ tmux list-windows

Do not copy the shutdown command into a general cleanup script. It uses SIGKILL and gives matching processes no opportunity to close files or clean up state. The utility does not persist network configuration, so stopping it does not require an undo command beyond closing the dashboard window it created.

5. Read failures without changing the network

If the interface is down, start with the exact name from iw dev. If it has no address, inspect the address pane and the current-boot journal before restarting services. If the route exists but the public ping fails, test the gateway separately and remember that some networks block ICMP. If the journal is unreadable as your user, use an authorised read-only journal query rather than running the whole dashboard as root.

A missing iw, ping, ccze or speedometer command changes what the dashboard can show. Install or enable such tools only after checking your distribution's package policy; wifi-status itself is not a package manager.