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.