Chase an intermittent RADIUS failure

"It randomly fails, then works on retry" is the hardest RADIUS complaint to act on, because a single test almost always passes. The fix is to stop testing once: run the check many times and let the aggregate (success rate, timeouts, latency spread) tell you whether it's packet loss, one bad node in a pool, or an overloaded server.

1. Measure it with --count

--count N (2–50) runs the whole check set N times and reports aggregate statistics instead of a single verdict: a success count, timeouts, and latency min / median / p95 / max. Now "sometimes" is a number you can quote:

# run the checks 20 times, 2s apart: turns "flaky" into a measured rate
authhound-probe radius test --server radius.corp.com \
  --secret-file /etc/authhound/secret --peap alice --count 20

Runs pause --interval apart (default 2s; a safety floor applies) so you're not hammering a production server. Raise --timeout from its 5s default only if the server is genuinely slow; a long timeout hides a reachability problem as latency.

2. Read the pattern

• A few requests lost, the rest fine → packet loss or an overloaded server. The p95/max latency being far above the median points the same way. Look at the network path and the server's load.
• All-or-nothing (all pass, or all time out) → not really intermittent. An all-timeout run is registration, secret, or firewall (see first-run timeouts); it just happened to be down when you looked.
• Auth fails on some runs but reachability never does → suspect a backend directory (LDAP/AD) that's slow or flapping, or one node in a pool with stale config. That's the next section.

3. The DNS round-robin trap: compare the backends

The classic intermittent cause: one hostname (radius.corp.com) resolves to a pool (a load-balancer VIP or several A records) and one node in the pool is misconfigured. Every request lands on a different backend, so it fails roughly one time in N and no single test is conclusive.

Give --server a comma-separated list of the individual backend IPs and the probe tests each one, side by side, so a broken node stands out immediately:

# the DNS round-robin trap: a hostname pointing at a pool where ONE node is bad.
# Test each backend IP directly, side by side, instead of the round-robined name.
authhound-probe radius test --server 10.0.0.11,10.0.0.12 \
  --secret-file /etc/authhound/secret --peap alice --count 20

If one IP FAILs (wrong secret, cert, or policy) while the other PASSes, you've found it. The load balancer was hiding it behind the shared name. Fix or pull that node.

Related

• RADIUS server not responding

  When the timeouts are total, not occasional: reachable vs. listening vs. silently dropping.

• EAP stalls mid-handshake

  Intermittent by device, not by run: large certs fragmenting on some paths. Different tool: --mtu.

• Monitor from a Raspberry Pi

  Once you know the rate, put a standing check at the site so the next episode is timestamped.