Hello Fernando -
On Tue, 19 Sep 2000, Fernando Costa de Almeida wrote:
> Im having the same problem here, and cant find the cause yet..
>
>
> Hugh Irvine wrote:
>
> > Hello Alexey -
> >
> > On Sat, 16 Sep 2000, Alexey A. Shavaldin wrote:
> > > Hello !
> > >
> > > I've experienced such a problem as hanging lines in RADONLINE table. We have
> > > about 3000 users, using authorization with Radiator 2.16 and MySQL server.
> > > Everything was OK, until we began to get lines in RADONLINE table, that stay
> > > there forever, without stopdate, so we have to delete them manually.
> > > Are there any possible solutions of this problem ?
> > >
> >
> > The first thing to do is to find out why the stop packets are going missing.
> > Check with your NAS vendor for software bugs and version upgrades, then put a
> > packet sniffer next to the NAS to ascertain what packets are actually being
> > transmitted, then move the packet sniffer to the Radiator host to verify that
> > all packets are reaching there, and finally check the Radiator trace 4 logs to
> > see if any packets are being received but not processed.
> >
> > Note that Radiator tries to be self-healing with regards to the session
> > database and will do a precautionary SQL delete for every new access request
> > received. You can also provide your own SQL queries if you use an SQL session
> > database.
>
> Can you explain in more details? Radiator do a delete for every new access
> request received? If so, how they control the max number of sessions?
>
Because Radius is UDP based (and because NAS equipment has software bugs),
Accounting Stop packets can and do go missing (which you already know).
Therefore, Radiator tries to be self-healing with regards to the session
database, by doing a precautionary delete for every Access request. This is
because, by definition, a session cannot already be present on a NAS port on
which a new call comes in. (If there had already been a session present, the
call could not have been received on that NAS port.)
After doing the delete from the session database, the maximum number of
remaining sessions for the user are checked, before returning an Access Accept.
This subject has also been discussed numerous times on the mailing list:
http://www.starport.net/~radiator
regards
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
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.
