Simultaneous-Use and radwho
Tuc at T-B-O-H.NET
ml at t-b-o-h.net
Thu Jun 12 23:11:00 CEST 2008
> 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
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. :) )
More information about the Freeradius-Users