radius cached results / cleanup_delay
p.mayers at imperial.ac.uk
Thu May 22 12:00:14 CEST 2014
On 22/05/14 09:08, Chris Knipe wrote:
> When a user authenticates multiple times in quick succession (I am talking
> about almost 30 or 40 identical requests at the same time) off to FR, not
> all the requests make it to my rlm_perl application (but they all make it to
> FR). I am suspecting that FR caches the results internally as documented by
> the cleanup_delay in the configuration file. That is fine and dandy
That's not what that does, IIRC. cleanup_delay relates to *truly*
duplicate radius requests i.e. same 5-tuple transport address, and
radius packet contents. It handles retransmits without repeating the
> doesn't affect me, and frankly, I appreciate it as it takes allot of
> processing time away from FR.
> The problem however, is that because not all the requests make it to
> rlm_perl, not all the responses from FR back to my application includes the
> Reply-Message / Configuration-Token attributes. This is especially
> troublesome for me on proxied requests which is sent to another home server,
> where there may be a delay before receiving a response from the home server.
I don't understand this last bit. Can you expand on it?
> So the question is, when FR caches results internally, does it only send an
> access-accept / access-reject back, or does it send ALL the attributes
> together with the access-accept / access-reject back?
As above, it's not "caching". The code deals with retransmits, and yes,
if it sees a retransmit, it re-sends the complete reply.
> Posting a radiusd -X is pretty much pointless as everything works fine under
> low usage (or one or two requests). The issue only presents itself when FR
> processes like 30 or 40 identical requests..
What does tcpdump/radsniff show when this happens?
More information about the Freeradius-Users