User disconnects but stays online in radius

Alan DeKok aland at
Tue Feb 19 15:40:45 CET 2013

Mobin Yazarlou wrote:
>  The more I read about this, the more complicated it gets!

  It's because UDP packets can be lost, and you can't realistically get
information out of the NAS.  The result is that any solution ends up
being complicated, and patchy.

>  I also found that sometimes removing the last accounting record for the
> locked user in the radacct table won't work and you need to set
> "/var/log/freeradius/radutmp" to null, to unlock that user.

  That depends on how you have the system set up.  If you do
Simultaneous-Use checking in SQL, you don't need to use radutmp.

>  I wish there was a table for online users in NAS and we could compare
> online user in NAS and online users in RADIUS and decide what to do.

  There should really be a separate table *only* for online users.  The
Simultaneous-Use checking should use that.  The table should also be
used to determine when a session has been closed, even if the NAS isn't
sending packets.

  It shouldn't be hard.  All it requires is for someone to do the work.

  i.e. the table should be similar to the current one, but with a few
fields deleted, and a few fields added.  It needs to track user, NAS,
NAS port, session start time, last update time, and maybe a few other

  When a session is started, a new row is inserted.  When a session is
stopped, the row is deleted.  The current accounting table can be used
to double-check for lost / delayed packets.

  There should also be a periodic shell script to clean up the table.
If a particular session hasn't seen updates for a long time, the script
should send a fake accounting "stop" packet to the server.  That lets
the server close the session.

  It's probably more complicated than that, but that's the basic idea.

  Alan DeKok.

More information about the Freeradius-Users mailing list