Hello Andrea -
Yes this is always a problem if you don't get proper accounting stop records.
Radiator is written so that the session database is maintained firstly by the accounting starts (insert) and accounting stops (delete), but also by the initial access request which causes a delete on the session database by using just the NAS-Identifier (or NAS-IP-Address) and the NAS-Port. This is based on the "traditional" NAS model in which the NAS-Port is unique and can only support one single connection at a time. In addition, if your NAS equipement is supported by one of the "NasType" options in the <Client ...> clause, you can configure that as well which will cause Radiator to query the NAS to determine whether or not a session marked in the session database is still actually connected (this may require additional Perl modules and/or NAS configuration - check the manual for details).
Hope that helps.
regards
Hugh
On Sunday, Sep 21, 2003, at 10:39 Australia/Melbourne, Andrea Brancatelli wrote:
Actually I'm using the MaxSession statement to avoid duplicate login to the network. Unfortunately that means that if a client hangs (so he doesn't logoff) he cannot re-login until I manually delete the session from the RadOnline table.
Is it possible to configure Radiator so that the second connection can get trough but would kill the first connection?
Should I use the afterlogin hook? can I have any hint?
:D
Thanks
NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening?
-- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
=== Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
