Hello Lufti -
On Mon, 08 May 2000, Lutfi YUNUSOGLU wrote:
>
> Hi
> We are using Radiator 2.1.5 on Solaris 2.7 and authenticate users with
> Oracle.
> We got some NAS and LAN based accounting problems. So we are using index on
> accounting table. Because of multi start-stop records for the same
> accounting information we have a lot of error mesages related to unique
> constraint.
> After we start with indexed accounting we start to have some SQL timeout's,
> which are bad for us.
> Yesterday I got this error before my SQL connection timed out:
> Sun May 7 18:27:52 2000: WARNING: Could not set socket read queue length
> for authentication to 1000000: No buffer space available
>
>
> How are this things related? I think because of indexed acounting table
> Oracle stucks to answer queries and NAS's opens to much auth & acct sockets.
> A solution maybe to decrease SQL timeout value and set the required kernel
> parameters.
>
I think you should start by determining why you are getting duplicate accounting
records. It seems to me you should only get one start and one stop for each
event, and that would improve the situation greatly. Check your NAS radius
timeouts and verify in a trace 4 that Radiator is indeed sending the correct
responses within the NAS timeout period. Then, consulting the same trace 4
debug from Radiator, check the timestamps on the accounting events (starts and
stops) and verify the length of time the SQL server is taking on each query -
this will show you immediately where the time is being spent.
>From the error message above, it would appear that you are trying to alter the
socket read queue length in Radiator with the "SocketQueueLength" parameter in
the configuration file? Note that this is the queue length for the socket(s)
upon which Radiator receives radius requests from your NAS(s), it has no effect
on your SQL database connection. Also, the NAS(s) do not open the auth and acct
sockets, they just send to the designated UDP port numbers on the radius host
that is specified in the NAS internal configuration.
If you do discover from the investigations above that your SQL server is
causing the problems because it is slow, I think you will need to address that
problem as a seperate exercise.
hth
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.
