Alan DeKok wrote:
but aborting the current packet instead of the new duplicate one can hardly be justified.
Nonsense. The duplicate one is an indication that the *NAS* has given up on the first packet. Spending more time processing the "current" packet is useless, because the NAS will ignore the Access-Accept for the old packet.
Absurd. The Dell PowerEdge 2950 w/ 2 quad-cores cannot itself without human intervention survive the "NAS attack" exactly due to having to give up on hundreds of requests per second not replied to in under 1 second,
Nonsense. Dell Poweredge 1850 with single quad-core has survived 3000 simultaneous re-authentications on my network and dropped 5 (yes, just five in total) requests as mysql got overloaded. Your perl script is way too slow to deal with such situation. Don't blame freeradius, Dell or whatever for a problem that is exclusively of *your* making. If you have to use such a slow script you will have to use several radius server and load-balance requests between them.
That is, not many (if any) of our "Receved ..." lines are due to what could be considered a NAS timeout, and they should be treated like "Discarding ...", that is, the new request should be dropped.
No, NAS qouldn't wait on your script to finish so it gave up and has tried again with a *different* request. Reason for that is that it isn't waiting for a response for an initial request any more. Discarding the second packet and replying to inital one in such a situation would be - well - stupid and a waste of time. NAS will just ignore that reply - it gave up on that request already.
"Fixing" FreeRADIUS to spend more time processing useless requests will only make the problem worse.
Please look at the line marked with ^^^ - it's where the error is logged and the current request is aborted, unless it was caught earlier by "Discarding conflicting packet", in which case the _new_ duplicate request is aborted, which is more correct.
No. You do not understand how RADIUS works. The code will NOT be changed to discard the new packet.
Perhaps someone more knowledgeable than you will be more able to assess all points involved.
Oh, good luck with that one :-D I somehow doubt that you will find someone more knowledgeable than Alan on this matter. Ivan Kalik Kalik Informatika ISP