A RADIUS request goes unanswered and the access device tries its secondary server - what must change?

## Two things that look the same on the wire An access device sent an `Access-Request (Code 1)` and nothing came back. It has two moves, and they are governed by opposite rules: - **Retransmit to the same server.** Send the identical packet again - same `Identifier`, same `Request Authenticator`. Nothing about it changes. - **Fail over to another configured server.** Build a **new** request - new `Identifier`, new `Request Authenticator` - even though the user, the credential and the circumstances are unchanged. Candidates reliably get the second one wrong, because from the operator's point of view it feels like the same login being tried somewhere else. ## Why a retry must be identical The `Identifier` is how a server recognises that it is looking at a copy of something it already has. If the first request arrived and the reply was lost, an identical retransmission lets the server answer from what it already did rather than treating it as a fresh login attempt. Change the fields and that recognition is gone: the server sees two separate attempts from the same access device, does the work twice, and any counting it does of attempts for that identity counts two. ## Why failover is a new request Both fields are scoped to one **client-and-server pair**: - the `Identifier` matches a reply to a pending request **on that pair**, and the access device may already have that value outstanding toward the secondary for something else; - the `Request Authenticator` is generated per request toward a particular server, and the verification of the answer that comes back is computed against it. The secondary has no knowledge of the exchange with the primary, so nothing is gained by carrying the old values across, and reusing them can collide with the access device's own outstanding state on that second pair. | | identical retry, same server | failover, different server | |---|---|---| | `Identifier` | reused | new | | `Request Authenticator` | reused | new | | what the receiver should see | a duplicate | a first attempt | | risk of getting it wrong | the login is counted twice | a collision with outstanding state | ## Silence is ambiguous, so probe instead of guessing No reply is not a diagnosis. It is consistent with at least four different faults: 1. the request never arrived; 2. it arrived and the reply was lost on the way back; 3. the server is alive but too busy to answer in time; 4. the server has no client entry for this access device, so it dropped the packet without answering - the classic symptom of a newly installed device that was never enrolled. The last of these is why an estate cannot infer server health from its own login traffic: a perfectly healthy server looks dead to a device it does not know. `Status-Server (Code 12)` closes that gap. It is an explicit liveness probe: a request whose only purpose is to find out whether the server is there and answering, independent of whether any user is trying to log in. An answer means the server is alive and reachable and willing to talk to this access device. No answer, repeatedly, is a much stronger signal than a user's failed login. ## What this looks like on a temporary site A showground network's access devices are configured with a primary and a secondary home server for each visiting organisation. On the first busy morning, one home server slows down under load rather than failing outright: - devices retransmit identically, which is correct, and the server can still tell those copies apart from new attempts; - once they give up on it, they compose fresh requests toward the secondary, which sees them as first attempts; - if the fields were carried across instead, the secondary's view of attempt counts and outstanding state would be wrong from the first packet. The separate question of how long a device should wait before deciding a server is dead is a device-configuration matter and an estate-wide risk decision, and it is not settled by this rule. What this rule settles is what the packet must look like once that decision has been taken.