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