User disconnects but stays online in radius

[Mobin Yazarlou]

On Mon, Feb 18, 2013 at 9:50 PM, Phil Mayers <p.mayers at imperial.ac.uk>wrote:

> On 18/02/13 18:02, Mobin Yazarlou wrote:
>
>> Hi,
>>   I am using freeradius v2.1.12 with MySQL support and noticed if a user
>> disconnect when radius server is down, NAS can not inform radius about
>> user being disconnected and radius assume user is still online after
>> coming up again. This restricts user from connecting again when you set
>> simultaneous-use to 1.
>>   Is there any solution for this? My NAS is pptpd on Debian 6.
>>
>
> RADIUS uses UDP, and NASes don't "save" accounting packets which don't get
> a reply; they usually send 1-5 attempts over a few seconds, then give up
> (or move to the 2nd RADIUS server).
>
> You need to take this into account.
>
> Possible solutions include some combination of:
>
>  1. Use interim accounting. Then, use a script to expire any sessions
> which have not seen accounting packets in X*interim-interval; X==3 for
> example
>
>  2. Setup a 2nd RADIUS accounting server and ensure your NAS has both
> servers configured. Use one of several configs to write the accounting data
> to a robust, replicated database. One way to do this is with the "robust"
> accounting that comes with FreeRADIUS.
>
>  3. Use a script to check your NASes active sessions and compare to
> accounting data at a certain interval.
>
> ...and so on.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/**
> list/users.html <http://www.freeradius.org/list/users.html>
>


Hi,
 That you for the quick reply Phil. The solutions you have provided brought
new thing into my mind.
 I was thinking about similar scenarios that I found out if NAS crashes,
same thing will happen. Clients will get disconnected due to NAS
unavailability and when NAS is unavailable, radius won't be notified about
users getting disconnected.
 By taking this into consideration, the most effective solution would be
the first or the third approach you have listed. And between this two
solutions, the last one seems to be easier to implement.

 Please correct me if I am wrong.

Thank you,
Moby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20130219/bb49ee3e/attachment.html>