Simultaneous-Use and radwho

Tuc at T-B-O-H.NET ml at
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
> 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

More information about the Freeradius-Users mailing list