Monitor RADIUS from a Raspberry Pi at a branch site

A Pi in the branch wiring closet is the cheapest way to answer "is RADIUS working from here?" — from the same network segment your users are on, not from the data centre. Install the probe once, schedule it, and let the exit code tell you when the branch loses authentication.

1. Install on the Pi

A 64-bit Pi (Pi 3/4/5 on 64-bit Raspberry Pi OS) runs the linux_arm64 build — a single static binary. Register the Pi's IP as a RADIUS client on the server first (see the quickstart), then:

# on the Pi (64-bit Raspberry Pi OS) — install the arm64 build
curl -sSL https://github.com/authhound/probe/releases/latest/download/authhound-probe_linux_arm64.tar.gz | tar xz
sudo install -m 0755 authhound-probe /usr/local/bin/authhound-probe

# store the shared secret in a root-only file (the probe refuses world-readable)
sudo install -d -m 0755 /etc/authhound
printf '%s' 'the-secret-you-registered' | sudo tee /etc/authhound/secret >/dev/null
sudo chmod 600 /etc/authhound/secret

2. One scriptable run

The two flags that make it monitor-ready: --json for a machine-readable line, and --strict so a warning (a cert expiring soon, a missing Message-Authenticator) also exits non-zero instead of passing quietly.

# a scriptable run: JSON out, and --strict so a WARN also exits non-zero
authhound-probe radius test --server radius.corp.com \
  --secret-file /etc/authhound/secret --json --strict

Exit 0 = all good, 1 = a FAIL or (under --strict) a WARN, 2 = a usage error. That stable contract is the whole basis for scheduling it.

3. Schedule it with a systemd timer

A oneshot service plus a timer is tidier than cron — you get the verdict and exit code in the journal:

# /etc/systemd/system/radius-check.service
[Unit]
Description=authhound-probe RADIUS liveness check
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/authhound-probe radius test \
  --server radius.corp.com --secret-file /etc/authhound/secret --json --strict
# so an exit code >0 (a FAIL, or a WARN under --strict) shows in journal/status

# /etc/systemd/system/radius-check.timer
[Unit]
Description=Run the RADIUS check every 5 minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now radius-check.timer
systemctl status radius-check.service   # last run's verdict + exit code
journalctl -u radius-check.service      # history on this Pi

…or with cron

If you'd rather use cron, log the JSON and raise something on a non-zero exit:

# cron alternative — every 5 min; log the JSON line, alert on non-zero exit
*/5 * * * * /usr/local/bin/authhound-probe radius test --server radius.corp.com \
  --secret-file /etc/authhound/secret --json --strict >> /var/log/radius-check.log 2>&1 \
  || logger -t radius-check "RADIUS check FAILED (exit $?)"

4. What this gives you — and what it doesn't

Now you know, on this Pi, whether the last check passed. That's genuinely useful at one site. What it doesn't give you: history you can look back through, a view across every branch at once, or an alert that reaches you when the Pi itself (or the site's uplink) is down.

That cross-site history and alerting is exactly what AuthHound's monitoring product is being built to do — it runs these same checks on a schedule from every site and tells you when one drifts. The waitlist below is the way in.

Related

• Wire the probe into your RMM / monitoring

  The full --json schema and exit-code table, with Nagios/PRTG-style check wrappers.

• Chase an intermittent failure

  If the branch check is flapping, --count turns "sometimes" into a measured rate.

• Troubleshooting the probe

  First-run timeouts, the NAT source-IP trap, and pinning the interface with --bind.