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?