> 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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
