Users can't connect — but the RADIUS logs look clean

Does this sound familiar?

• Users on one floor can't connect. The dashboard — or your radiusd -X log — shows zero failed requests, because the requests never arrived.

• "It works when I test it." Then it fails again at 3am, and by the time you look, it's working again.

• Everyone's getting rejected after a change and you can't tell if it's the shared secret, a firewall, or the server not knowing your NAS.

• Wi-Fi died for the whole site this morning and nothing was touched — except a certificate quietly hit its expiry date.

Every one of these is invisible in the server's own logs and painful to prove from the client side. The probe reproduces the exact conversation your switch or AP has with the RADIUS server — so you stop guessing.

Works with any RADIUS server

If it speaks RADIUS, the probe can test it — it authenticates as a NAS would, so it doesn't care what's behind the server.

What it checks

For EAP-TLS, point --client-cert / --client-key at a client certificate (reuse a device's, or issue one test cert) — the probe says exactly why a login fails: untrusted CA, expired cert, or a server policy reject. Full cert-prep steps are in the README.

Like eapol_test, but you can actually read the output

eapol_test and radtest are excellent at what they were built for — eapol_test is the reference EAP client with the widest method coverage anywhere, and radtest is the fastest "does an Access-Request come back" check on any box with FreeRADIUS. The probe sits in a different spot: the diagnosis workflow.

They compose: use the probe to localise the failure in seconds, then drop into eapol_test for a protocol-level trace of the one broken method. The full comparison — install and config burden, a working eapol_test PEAP config, and when the classics are still the better tool — is on this site, maintained against the repo's COMPARISON.md.

Run it in two minutes

Single static binary — no runtime, no dependencies. Grab it, or use Docker:

Prefer step-by-step? The docs cover install, registering the probe, the flag reference, and reading the output — and the task recipes walk real jobs end to end (test a Windows NPS server, run from Docker, monitor from a Raspberry Pi, chase an intermittent failure, EAP-TLS stalls, RMM scripting, BlastRADIUS, VLAN assignment).

# download the binary (Linux/macOS/Windows on the releases page)
curl -sSL https://github.com/authhound/probe/releases/latest/download/authhound-probe_linux_amd64.tar.gz | tar xz

# keep the shared secret off the command line — out of shell history and `ps`
export AUTHHOUND_RADIUS_SECRET='shared-secret'

# test a server — add --peap <user> for a real PEAP-MSCHAPv2 login (prompts for the password)
./authhound-probe radius test --server radius.corp.com --peap alice

# or run it with Docker (multi-arch, distroless image)
docker run --rm -e AUTHHOUND_RADIUS_SECRET ghcr.io/authhound/probe radius test --server nps.corp.com

# machine-readable output for scripts / RMM
authhound-probe radius test --server radius.corp.com --json

Reachability, shared-secret, and certificate checks run with no credentials. Add --peap <user> (PEAP-MSCHAPv2), --pap <user> (PAP), or --client-cert/--client-key (EAP-TLS) to test a real login — you're prompted for the password (no echo), or set AUTHHOUND_RADIUS_PASSWORD for unattended runs. The tool never needs a secret or password on the command line, where it would leak into shell history and ps. See the full flag list on GitHub.

Every release is checksummed and keyless-signed with Sigstore cosign — bound to the GitHub release workflow, no long-lived key — so you can prove a download is genuine before running it on a shared box. Copy-paste verification steps are in the README.

Browse releases & downloads →

One-time setup: because the probe acts as a NAS, add its IP as a RADIUS client on your server (a client{} block in FreeRADIUS, or a RADIUS Client in NPS) with a dedicated shared secret. Use a least-privilege test account — never a real admin login. If you use MFA, point it at a test account exempt from the second factor so the primary path can be checked cleanly.

Where sysadmins run it

Put it where your clients live, not next to the server — the firewall path between user VLAN and RADIUS is exactly where the invisible failures hide. Common homes: a container on a Synology/QNAP NAS or a utility VM, a tiny 1-vCPU VM on your existing hypervisor, a systemd service on the box already running your monitoring, or a Raspberry Pi at a branch site.