Simultaneous-Use oddness.
Matthew Schumacher
matt.s at aptalaska.net
Wed Jul 31 16:48:18 CEST 2013
Alan,
Thanks for your reply. I see your point. But this does create an issue
when you deprecate a nas when users are connected (which isn't ideal but
does happen) because now the session will never close and radius doesn't
assume that a missing nas also means missing session, nor does it pass
it to checkrad which would determine the same.
The solution is simple though (and for the edification of others
searching the list) simply modify the simul_count_query to only find
sessions that are on an active nas. This assumes that you also are
storing the clients information in the db (using nas_query) which I am.
Thanks for your help.
schu
On 07/20/2013 04:58 AM, Alan DeKok wrote:
> Matthew Schumacher wrote:
>> When I have a session that didn't get expired in a SQL database, and the
>> user tries to connect then freeradius correctly checks the nas using the
>> checkrad script *UNLESS* the nas is no longer defined in the clients.
>> If the nas is missing, radius doesn't bother to call checkrad, and
>> rejects the login as a multiple login.
>
> Which is what it should do.
>
>> So if I deprecate a nas, remove it from the db, then restart freeradius,
>> the next request comes in, free radius finds the session to be open, but
>> then neither checks checkrad or accepts the user. The user is now
>> unable to authenticate until I close the session in the SQL database.
>
> Because the sessions are still open. When you delete the client from
> the DB, you should close all user sessions for that client. This is
> because the client won't do it... it's no longer a client.
>
>> Shouldn't freeradius call checkrad anyway and pass it the
>> ip/session/user/port for the non-existent nas and let the checkrad
>> script return 0, then let the user on? That's what I would have though
>> should have happened.
>
> No. Deleting a client means that the client doesn't exist. You
> shouldn't run checkrad against a client which doesn't exist.
>
> This is really an administration issue.
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
More information about the Freeradius-Users
mailing list