Copy the configs to a test machine. Run "radsniff" on the production machine to grab packets. Play them back on the test machine. Run radiusd -X on the test machine.
Ok, wasn't aware of the functionality. I don't see a "radsneeze", so I'm guessing you pipe them back in via echoing it to radclient?
But it seems somehow they are able to "race" it :
Wed Jun 11 18:19:53 2008 : Auth: Login OK: [regtum14/<CHAP-Password>] (from client SBC-2393 port 4 cli 00-13-02-20-F9-DC) Wed Jun 11 18:19:53 2008 : Auth: Login OK: [regtum14/<CHAP-Password>] (from client SBC-2393 port 2 cli 00-1B-9E-C4-9E-CD
The NAS is delaying the accounting packets.
DD-WRT running O-L-D Chillispot.
Would switching to SQL be better? (Or is this something that MUST have a radiusd -X to resolve?)
No. The way to fix it is to fix the code so that the user is marked "conditionally logged in" for 10-20 seconds after the Access-Accept. if there's no Accounting start, that record is erased. Otherwise, the accounting start marks the users as "really logged in".
That way, when the second login request comes, the server discovers that the first user is likely to be logged in, and rejects the second request.
I'd love to help, but I'm a "C compiler" (I can find includes/functions and missing libraries) and not a "C programmer". Is this something I should put a bug report in about a "race condition" or "Dealing with slow NAS accounting" or some other title? Is there someone on the list that maybe would be interested in working on a patch (I'm a great tester. :) ) Thanks, Tuc