> I'm having a problem with records being 'stuck' in the RADONLINE
> table when user's disconnect. Then when they try to reconnect
> they get rejected because it appears they are still online.
> Has anyone ever encountered this problem before? Anyone
> know what the problem is? It doesn't happen all the time
> and I can't seem to isolate what the cause may be.
Accounting packets can and do get lost, they are UDP packets after all and
they're not guaranteed to arrive at the destination. If an accounting start
record correctly arrives on your radius server, the user will appear in
RADONLINE. If the accounting stop record gets lost, it will never get removed
so the user is essentialy "stuck" in your RADONLINE database.
The only solution is to *check your facts* before rejecting a user and the way
to do this with Radiator is to specify the NAS Type in your <Client> clause,
like this:
<Client 192.168.0.1>
Secret verysecretindeed
NasType AscendSNMP
</Client>
This tells Radiator to use SNMP to contact your NAS and verify if the port as
specified by RADONLINE is indeed occupied. If it is not, the entry will be
removed and the user will be able to login. If it is, the user will be denied
access.
Why do accounting packets get lost you ask? Overloaded (or temporary
busy) ethernet segment, busy radius server host or busy NAS, phase of the
moon, etc.
Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia
E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
