Hello Hugh,
Many thanks for the given information...
The questions below can be useful to go a bit further and solve this Problem:
What are the exact conditions, when the Radioator sends TimeOut Error Message?
How does the Radioator communicate with SQL (Oracle) Server? (OK by using DBI and DBD but how?)
How does the Radiator understand, that the SQL server is down or unreachable?
For which packets does the Radiator looking for, to verify that the deletion process is OK?
Is DELETE transaction commited right after the proccess, or is there any delay?
Best Regards,
Emin TAHRALI
Siemens Business Services
<mailto:[EMAIL PROTECTED]>
-----Original Message-----
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 28, 2000 1:40 PM
To: Emin TAHRALI; '[EMAIL PROTECTED]'
Subject: Re: (RADIATOR) SQL Timeout & SNMP Query
Hello Emin -
On Wed, 28 Jun 2000, Emin TAHRALI wrote:
>
> Hi,
>
> We are using two radiators working simultaneously, and AuthBy SQL
> authentication.
> We have some troubles with SQL Timeout Problem.
>
> The Error Logs are as below:
>
> 1. Error Log of 1st Radiator
> Sun Jun 25 13:31:13 2000: ERR: do failed for 'delete from RADONLINE where
> NASIDENTIFIER='213.186.130.66' and NASPORT=090': SQL Timeout
>
> 2. Error Log of 2nd Radiator
> Sun Jun 25 13:33:07 2000: ERR: do failed for 'delete from RADONLINE where
> NASIDENTIFIER='213.186.130.66' and NASPORT=090': SQL Timeout
>
> Could you please explain the conditions and the behaviour of Radiator, when
> Radiator sends these error messages.
>
This occurs because your SQL server does not respond to the SQL query shown.
When a query times out, Radiator considers that SQL server to be down and will
wait for 600 seconds by default before trying again.
Have a look at section 6.25.4 and 6.25.5 in the Radaitor 2.16.1 reference
manual.
> We guess, this problem occurs because of the SNMP query in one way or
> another, but it is not ceratin.
No. It is just because the SQL server did not respond.
> The cause of the problem can also be a deadlock in SQL or something else.
>
Yes.
> Now I need to know, when the users connection is checked by the SNMP Query.
> Below is a part of Trace 4 log. Where is the right location of the SNMP
> query
> in this sequence?
>
> And it is also not clear, why the users session is deleted before a SELECT
> query is made on the RADONLINE table.
>
What happens is this. When Radiator receives an Access-Request, it first of all
does some housekeeping and deletes any old session database record for that NAS
and Port number. This is because we might have missed a Stop record, and also
because by definition there cannot be an existing session for that NAS and Port
combination. Secondly, Radiator verifies the session database to check on
simultaneous use limits. Thirdly, only if there are already the maximum number
of simultaneous sessions for the user will Radiator then go and check with the
NAS(s) whether the sessions in the session database are still present.
> ....
> SSun Jun 25 17:47:27 2000: DEBUG: Handling request with Handler
> 'Realm=DEFAULT'
> Sun Jun 25 17:47:27 2000: DEBUG: Rewrote user name to onurmersinlioglu
> Sun Jun 25 17:47:27 2000: DEBUG: Deleting session for onurmersinlioglu,
> 213.186.131.66, 198
> Sun Jun 25 17:47:27 2000: DEBUG: do query is: delete from RADONLINE where
> NASIDENTIFIER='213.186.131.66' and NASPORT=0198
> Sun Jun 25 17:47:27 2000: DEBUG: Query is: select NASIDENTIFIER, NASPORT,
> ACCTSESSIONID from RADONLINE where USERNAME='onurmersinlioglu'
> Sun Jun 25 17:47:27 2000: DEBUG: Handling with Radius::AuthSQL
> Sun Jun 25 17:47:27 2000: DEBUG: Handling with Radius::AuthSQL
> Sun Jun 25 17:47:27 2000: DEBUG: Query is: select
> PASSWORD,CHECKATTR,REPLYATTR || SESSIONFILTER || SESSIONFILTERVALUE ||
> to_char(nvl(TOTALSESSION,2592000)) from SUBSCRIBERS,SESSIONFILTERS where
> USERNAME='onurmersinlioglu' AND
> (to_date(to_char(EXPIREDATE,'dd.mm.yyyy'),'dd.mm.yyyy')
> >=to_date(to_char(SYSDATE,'dd.mm.yyyy'),'dd.mm.yyyy') OR EXPIREDATE IS NULL)
> AND subscribers.SESSIONFILTERID = sessionfilters.SESSIONFILTERID
> .....
If you have defined a Simultaneous-Use CHECKATTR above, you may also check the
session database after the above query.
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.
