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.