One install, one browser tab, and the edition of the Toolbox with no wired ceiling. This is the whole procedure, what you get for it, and the two things that will break it later.
The short version. You run one command on a WLAN Pi you already own. It stands up a small web server on the Pi and you open the Toolbox from any browser on the same network. Nothing is installed on the machine you browse from, and nothing is baked into the image: every secret is generated on the device at first run.
Every other edition of the Toolbox runs on a device that holds the operating system at arm's length. A phone will not decode a DHCP packet for you. A sandboxed Mac will not either. Those are platform limits, not gaps in the app, and no amount of engineering removes them.
The WLAN Pi is Linux, it is yours, and it says yes. So this is the edition with no wired ceiling:
That makes it the reference platform rather than the afterthought. When an edition on another platform cannot answer a question, this is the build that shows you what the honest answer would have been.
| Item | Detail |
|---|---|
| A WLAN Pi | Any of them. There are two shipping models, the R4 and the M4+, and the Toolbox has been run on both on WLAN Pi OS 3.4.4. The R4 with two Panda 6E adapters, the M4+ with a Panda plus an Intel BE200. |
| Internet on the Pi | For the install only. Afterwards it runs happily on an isolated network. |
| Your sudo password | The one you set on the Pi's first boot. WLAN Pi OS ships as wlanpi/wlanpi and forces a change, so there is no default left to guess. |
| A browser | On any machine that can reach the Pi. Phone, tablet, laptop. Nothing to install there. |
| Optional: a USB Wi-Fi adapter | A Panda PAU0F AXE3000 is proven on our own hardware over a year of field use. It is MediaTek MT7921AU silicon, the same USB ID the WLAN Pi project marks recommended, and monitor mode and 6 GHz both work. |
Step 1. Install it
One command, from a shell on the Pi:
curl -fsSL https://raw.githubusercontent.com/keithrparsons/wlan-pros-toolbox-pi/main/pi-install.sh | sudo bashIt checks it is actually on a WLAN Pi first and refuses loudly if it is not, because on a plain Debian box it would install a web server and a proxy that signs against a platform secret that is not there, and you would meet that later as a confusing error instead of now as a clear refusal.
Then it fetches the current release, unpacks it, and installs. It ends by printing INSTALL_OK and a status block. If you do not see INSTALL_OK, it did not finish, whatever else scrolled past.
It is safe to re-run. The one thing to know: re-running restarts the Wi-Fi supplicant, so it briefly drops any Wi-Fi association the Pi itself is holding. If you are reaching the Pi over its own Wi-Fi rather than over Ethernet, you will bounce for a moment.
Step 2. Check it answers
curl http://<pi-ip>:8080/toolboxapi/health # {"model":"R4"}
curl http://<pi-ip>:8080/toolboxapi/wifi # the Pi's OWN associationStep 3. Open it
From any browser on the same network: http://<pi-ip>:8080/
Go straight to Wi-Fi Information. It should show the Pi's own association. If it instead tells you to download the native app, the web bundle deployed but the backend did not, and that is the one failure worth reporting rather than working around.
A normal install serves plain HTTP with authentication off. That is the right default for a bench tool on your own bench, and the wrong one anywhere else. Anyone who can reach the Pi can reach everything it exposes, and that includes tools that send arbitrary packets and wake machines on the LAN.
There is a hardened build path for the other case. It turns on TLS and HTTP authentication, forces key-only SSH, strips passwordless sudo, and regenerates every secret on first boot. If the Pi is going anywhere near a client site, use that one. It is a golden-image build rather than something you run on a working card, and it is deliberately not what the normal install does.
Do not expose port 8080 to the internet. There is no version of this where that is a good idea.
The Pi answers 27 endpoints behind the web app. That number is counted from the proxy's own routing table, not estimated.
| Group | What it does from the Pi |
|---|---|
| Radio and association | Scan with a chosen radio, list scan-capable interfaces, read the Pi's own association, connect and disconnect. On a multi-radio Pi the radio picker is the point: you scan with the adapter you chose, not the one the OS preferred. |
| Wired and addressing | Interface and link tables, neighbor table (ARP and NDP), and the full DHCP option decode that no phone can give you. |
| Reachability | Ping, a bounded ping series you can plot, traceroute, and a connection test. All measured from the Pi's position on the network rather than from your laptop. |
| Discovery | Host and service discovery, ping sweep across a CIDR, and a TCP-connect port scan. |
| Names and ownership | DNS, WHOIS, IP geolocation, and BGP/ASN lookup. Useful when the question is "whose network is this actually" rather than "is it up". |
| Web and transport | TLS certificate inspection and HTTP header inspection, run from the Pi so you see what the Pi sees. |
| Throughput | The Pi's own uplink throughput, plus a local sink so you can measure the browser-to-Pi hop separately. Two different questions, deliberately not merged. |
| Active tools | Wake-on-LAN and a custom packet sender. These transmit. Treat them accordingly, and see the security note above. |
An apt upgrade can silently undo part of this install, and nothing will tell you.
Three pieces of the build live inside files that Debian packages own. When those packages update, your copies are replaced with the stock versions. The install does not crash. Scanning simply stops working, and nothing announces why.
That is what the update tool is for:
sudo toolbox-update status # what is installed
sudo toolbox-update check # has anything drifted?
sudo toolbox-update repair # put it backThis path is proven rather than assumed. We reverted the patches deliberately, watched check catch it and the scan die, then watched repair put it back. If you ever run a system update on that card, check is the fast way to find out what it cost you.
Worth knowing, because it explains a stock-image behaviour that looks like your fault:
The stock image ships no systemd unit for wpa_supplicant, and points its D-Bus activation at a path that does not exist. On top of that, the platform service asks for a dummy driver at two call sites. All three break scanning, on a completely fresh card, before you have done anything.
The installer repairs the platform's own D-Bus supplicant path and lets the platform service drive it. An earlier version of this kit ran its own supplicant instead, which was a workaround that lost a race on every reboot. That hack is not installed here, and is removed if found. After a correct install, a scan returns real neighbors.
INSTALL_OK. The install did not complete. The last error before it stopped is the real one; earlier warnings are usually noise.sudo toolbox-update check first. If something drifted, repair is the answer. If nothing drifted, the radio may not be scan-capable.