Simultaneous-Use and radwho
Hi, I haven't been given authorization to do a radiusd -X yet, but I'm seeing something in my logs that I don't get . User is logging in from multiple times, so I put on Simultaneous-Use and it goes against the radutmp. So I test it by hand and I get in radius.log Wed Jun 11 17:30:45 2008 : Auth: Multiple logins (max 1) : [regtum14/TESTING] (from client localhost port 1812) Ok, good. So I reset the device and make sure it gets an: Wed Jun 11 18:17:04 2008 : Info: rlm_radutmp: NAS 192.168.75.39 restarted (Accounting-On packet seen) Wed Jun 11 18:17:04 2008 : Info: rlm_sql (sql): received Acct On/Off packet 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 Would switching to SQL be better? (Or is this something that MUST have a radiusd -X to resolve?) Thanks, Tuc
Tuc at T-B-O-H.NET wrote:
I haven't been given authorization to do a radiusd -X yet,
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.
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.
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. Alan DeKok.
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
Tuc at T-B-O-H.NET wrote:
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?
Yes.
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. :) )
File a bug report. But there are no plans to work on it. Alan DeKok.
participants (2)
-
Alan DeKok -
Tuc at T-B-O-H.NET