Cleanup of the "id" between NAS and radius server

Arran Cudbard-Bell a.cudbardb at
Tue Nov 19 18:33:04 CET 2013

> I have posted my wireshark screen at:
> When I am looking at my TCPdumps (debugging duplicate requests) I see a duplicate request come in at Frame 6963
> Frame 5475 at 10:20:07 - Access-Request id 76
> Frame 5482 at 10:20:07 - Access Challenge response to 5475 id 76
> Frame 6963 at 10:20:13 - Duplicate Request says response to this request id 76 is in frame 5482
> Now, Frame 6963 is a full 5 seconds past the Access-Challenge of Frame 5482. 

We'd have to see the debug output to know what was actually going on there. 

Wireshark is quite limited in it's duplicate detection. Just because it says
there was a duplicate response, it does not mean the cached response was
sent in response to a duplicate request.

The NAS could be retransmitting something like an EAP Identity-Response, 
which would prompt an identical Access-Challenge from FreeRADIUS each time
it was sent.

The EAP fragment is so short that it suggests something like that may be 
the case.

> My question is, is it the "cleanup_delay" setting that cleans up old identifiers for re-use? 

It cleans up cached responses. The NAS should NOT re-use an identifier unless
it has either timed out the request or received a response.

Using the same ID alone does not make a request a retransmission. It has to
be a combination of SRC port, SRC IP, DST Port, DST IP, ID and I believe in the
case of FreeRADIUS the contents of the authenticator field.

If the authenticator field contents changes but the rest of the values are the
same, the old response should be removed from the cache, and the server should 
treat the Access-Requests as a new request.

The key word there being *should*, i'll let Alan clarify whether it does or

> Does the "max_requests" value have any effect on when the identifiers are ready for re-use?



Arran Cudbard-Bell <a.cudbardb at>
FreeRADIUS Development Team

More information about the Freeradius-Users mailing list