|
Hi Hugh,
After going through the documentation on Radiator,
i found that the Radiator by default, clears all sessions on the online
(session) table if the NAS is rebooted. This is OK under normal
circumstances. The problem we have is that, when radius (radiator) is
restarted OR when a large query is being executed (on the Authentication
table - not the online session table), the sessions for a particular NAS
are cleared.
Is there some parameter/s (eg. a Timeout
parameter) that can be changed or inserted into the config file that would
ensure that a certain time has elapsed before the session table is
cleared??
Thanks and regards
Mustafa
----- Original Message -----
Sent: Tuesday, 13 February 2001 02:50
PM
Subject: Re: Re: (RADIATOR) Incorrect
online users
Hello Mustafa -
We have checked
the network usage using a sniffer and the usage is not more than 20% of
capacity at peak. We did run radius in trace 4 debug mode for a while but
were not able to tell much from the file as to why the online users are
incorrect in the RADONLINE.
The trace 4 will show everything that is happening.
BTW - I am travelling this week, and I could not download a 4mb trace
file.
We did notice that
each time a a user attempts to connect, his records is first deleted
from the RADONLINE and inserted again. Please confirm if this is the
way the radius functions or is it an error.
Yes, Radiator tries to be self-healing in the face of lost stop packets,
so it always does a pre-emptive delete of the session database record for the
NAS-IP-Address and NAS-Port that is present in the request.
I would like to
mention that the users in the RADONLINE drop when the authentication
database is locked for a long time. This happens when a query
is executed for checking the status of the users. This query takes
about 30 seconds to execute and when its done, the RADONLINE
entries from the Tigris drops down drastically. Please
advise.
It may very well be that you are getting a timeout on your SQL
connection, which results in Radaitor not trying the connection again for 10
minutes. I could well imagine that not updating the session database for that
long would cause serious problems. An SQL query that takes 30 seconds will
cause major problems and should be fixed.
There is one other
problem that we are facing at the moment. If a user is online and another
attempt is made to log on using the same username password, the second
attempt is not rejected outright, instead, the user gets a pop up window
requesting the username and password again. The user is prompted for a valid
username and password up to 20 times before the session is dropped. I was
trying to look up how to limit this to three but was unable to find help in
the documentation and on the web site. I am told that the NAS does not
drop the call because of incorrect radius attributes. Please
confirm.
I have no idea why this would be happening. If an access is rejected, an
Access-Reject is returned to the NAS, there are no attributes involved.
hth
Hugh
--
NB: I am
travelling this week, so there may be delays in our
correspondence.
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.
|
