radius cached results / cleanup_delay

[Phil Mayers]

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 
processing.

> 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?