Hi, > Our radius-server timeout is high enough: 4 minutes. Once again: I > suppose that what freeradius thinks of as "Received conflicting packet > ..." are rather a bit delayed packets normally treated as "Discarding > conflicting packet ...", i.e. they arrive at freeradius in maybe 1.01+ > second after the first request, but freeradius drops the current request > instead of the new one. Soon I'm gonna rebuild freeradius with changed > tv_sec and check that.
huh? do you not understand the basic context of this issue? if the NAS has sent a repeat RADIUS packet then it means that the original packet has already been timed out and the NAS should NOT accept an 'accept' response on that original packet. your RADIUS timeout is 4 minutes??? the highest sorts of values that you should ever expect a RADIUS request to be 'on the wire' is around 12 seconds - and thats for proxied packets that have travelled around the world. what OS are you running on that Dell? The only thing I can think of is one of the dodgy RedHat buggy releases where there was a MASSIVE Perl startup penalty - thats been fixed in all recent distros (unless its come back again). we have single and dual core Dell system (manufacturer really doesnt matter - we're still talking about basic PC hardware - that can do several thousand auths per second...and thats with Perl involved too. i wonder if you are killing your RADIUS via some others task - eg its the accounting thats blocking the threads because you are accounting to eg SQL rather than to disk and using buffered-sql (very very common issue) alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
