skip to content

Over a link that drops packets, an Access-Request draws no RADIUS reply — what can the access device not distinguish?

level: seniorimportance: should knowfreq 46%

answer

  1. silence carries no verdict
  2. three causes, one symptom
  3. a refusal would have been a packet
  4. retransmit byte-identically, same Identifier
  5. IRT, MRT, MRC, MRD are recommendations

basics

~20 s

Three states: the request never arrived, it arrived and the reply was lost, or it arrived and was discarded without an answer. Silence is never a refusal — an Access-Reject is an explicit packet — so the device can only retransmit.

solid answer

~40 s

A timeout tells the device nothing about the server's decision. The same silence is produced by an `Access-Request` that never arrived, by an `Access-Accept` **or** an `Access-Reject` that was lost coming back, and by a request the server dropped without answering — RADIUS defines no error or negative-acknowledgement packet, so an unrecognised sender or a packet that fails validation simply disappears. The only move is to retransmit, **byte-identically**: same `Identifier`, same Request Authenticator, so the server can recognise the duplicate. RFC 5080 recommends a timer model — an initial retransmission time of about 2 seconds, doubling with a random offset up to a cap, bounded by a retry count and a total duration — and those are recommended defaults, not protocol constants.

code

pseudocode · 14 lines
pseudocode
function send_access_request(request):
    wait_time = IRT plus small random offset      # IRT recommended 2 s
    attempts  = 0
    elapsed   = 0
    loop:
        send(request)          # same Identifier, same Request Authenticator
        reply = wait_for_reply(wait_time)
        if reply is not none:
            return reply
        attempts = attempts + 1
        elapsed  = elapsed + wait_time
        if attempts >= MRC:  return no_answer     # MRC recommended 5
        if elapsed  >= MRD:  return no_answer     # MRD recommended 30 s
        wait_time = min(2 times wait_time, MRT) plus small random offset

go deeper

for a junior

The point to hold on to is that no reply is not the same as a refusal: a refusal is an Access-Reject packet, and silence means the exchange did not finish.

for a middle

Explain the three causes a timeout cannot separate, and that the client retransmits the identical packet — same Identifier, same Request Authenticator — rather than composing a new request.

for a senior

Demonstrate the operating knowledge: the recommended IRT/MRT/MRC/MRD model as defaults rather than constants, why jitter matters when a whole fleet reconnects at once, and using Status-Server to probe rather than burning user attempts.

for a principal

The judgment is about where reliability should live. Retry parameters tuned per device against a lossy link is a fleet-wide configuration problem; moving to a connection-oriented transport relocates it into the transport, at the cost of touching every access device in the estate.

## What silence can mean RADIUS rides on UDP, which acknowledges nothing. When a request goes unanswered, at least three genuinely different situations produce exactly the same symptom: 1. **The `Access-Request` never reached the server.** It was dropped in transit and the server has no idea an attempt was made. 2. **The request arrived and the reply was lost.** The server decided, sent `Access-Accept` or `Access-Reject`, and the datagram died on the way back. The server believes it answered. 3. **The request arrived and was discarded without a reply.** It came from an address the server does not recognise as a client, or it failed validation, or it was malformed. There is no packet for the server to send in these cases — the protocol defines no error reply for the access exchange — so it stays silent. Nothing in the device's view separates these. A capture at the server is the only way to tell case 1 from cases 2 and 3. ## Silence is not a verdict The most damaging misreading is to treat a timeout as a refusal. A refusal is a packet: **`Access-Reject` (Code 3)**. If the server denied the attempt, a datagram was sent. The absence of one says only that the exchange did not complete — and a lost accept and a lost reject are indistinguishable, so no negative inference of any kind is available from the silence itself. ## Retransmit, and retransmit identically The client's only recourse is to send the request again, and it must send **the same request**: - the same `Identifier`; - the same Request Authenticator; - the same attributes, unchanged. That byte-for-byte sameness is what allows the server to recognise a duplicate and resend the answer it already computed, rather than authenticating a second time. Change any of those fields and it becomes a new request, which is exactly wrong when the first one may already have been processed. ## The recommended timer model RFC 2865 specifies no retransmission algorithm at all. RFC 5080 supplies one, borrowed in shape from other UDP protocols, with four parameters: | Parameter | Recommended default | What it bounds | |---|---|---| | IRT | 2 seconds | The wait before the first retransmission | | MRT | 16 seconds | The longest any single wait may grow to | | MRC | 5 | How many times one request may be retransmitted | | MRD | 30 seconds | The total time spent retrying one request | The wait roughly doubles each round up to MRT, and the attempt ends when MRC or MRD is reached, whichever comes first. **These are recommendations, not protocol constants** — implementations expose them as configuration and the values differ in the field, so an answer that states them as fixed is overclaiming. ## Jitter, and a fleet that reconnects at once Each wait carries a small random offset, and this is not cosmetic. Consider a link that drops entirely and then recovers: without jitter, every device behind it retransmits on the same schedule, and the server receives the whole estate's backlog in synchronised bursts. Each burst is heavy enough to cause losses, which produce another synchronised round of retransmissions. The random offset spreads the recovery out so the server sees a rising curve rather than a wall. ## Asking directly instead of inferring Inferring server health from failed logins is poor practice: it consumes real users' attempts as probes. The protocol offers a direct question instead — **`Status-Server` (Code 12)**, reserved as experimental in RFC 2865 and later specified in RFC 5997 for exactly this purpose. A device can ask whether a server is answering without putting a user's attempt at risk. ## When the transport is reliable The whole problem above is a property of UDP. Where RADIUS runs over a connection-oriented transport, retransmission belongs to the transport, and a broken connection is visible as a broken connection rather than as silence. The ambiguity does not vanish — a connection can still drop between request and reply — but it narrows, and the application-layer timer model changes accordingly. ## What a senior answer sounds like Name the three indistinguishable causes, say plainly that a rejection would have been a packet, describe the byte-identical retransmission and why it must be byte-identical, and treat the timer values as recommended defaults. Reaching for `Status-Server` as the way to ask the question directly is the detail that separates someone who has operated this from someone who has read it.

  • How can a device tell a dead server from a lost reply without spending a user's login attempt?
    By asking directly with `Status-Server` (Code 12), reserved as experimental in RFC 2865 and specified for liveness checking in RFC 5997. An answer proves the server is processing packets; inferring the same thing from failed `Access-Request` attempts costs real users their logins and still cannot separate loss from silence.
  • Why must the retransmission repeat the Request Authenticator as well as the Identifier?
    Because the pair is what marks the packet as the same request. A server distinguishes a duplicate from a genuinely new request with a recycled Identifier by comparing the Authenticator, so changing it turns a retry into a second authentication of the same user at the worst possible moment.
  • Why does the random offset on each wait matter across a fleet?
    When a shared link recovers, every device behind it would otherwise retransmit on identical schedules, hitting the server in synchronised bursts heavy enough to cause fresh losses and another synchronised round. Jitter spreads the recovery into a curve the server can absorb.

saying these in an interview costs you the question

  • Reads a timeout as the server having denied the login.
  • Changes the Identifier when retransmitting the same request.
  • Expects an error packet when the server discards a request.
  • Retries on a fixed interval with no randomisation across a fleet.
  • States RFC 5080's timer defaults as protocol constants.
  • Assumes a lost accept looks different from a lost reject.