radius cached results / cleanup_delay

[Chris Knipe]

Hi All,

First and foremost, well done with FR 3.  Very nice revamp and whilst I did
put off upgrading for a long time, I'm very pleased that I did eventually
take the time to upgrade.  Proud to say I'm running 3.0.3 now.

Everything is working fine as expect, but I am experiencing one small issue
that did not represent itself whilst using FR2.1.10.

I am using FR to authenticate users with AAA in a custom application (not
the traditional PPP type of scenario).  The application sends of the request
to FR, and I almost exclusively rely on rlm_perl to process and authenticate
the user.  rlm_perl crafts a specialised Reply-Message attribute, together
with a Configuration-Token attribute and sends this back to the application
for Access-Accepts, as well as Access-Rejects.

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

What is interesting to me, is that even when using the detail module to log
all the auth-replies, the log indicates that ALL attributes are always sent.
But when the packet gets to my application, the application cannot find the
attribute.  Surely, an attribute cannot just "magically" disappear from a
packet?  I'm not saying FR is to blame here per say, but I find it hard to
believe that anything other than FR can be crafting and sending a packet to
my application, or that there is something magical between the FR box and
the application box that modifies the packets.

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? 

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

Many thanks, and hopefully someone can shed some light on the cleanup_delay
for me.

--
Chris.