Re: [RADIATOR] SQL Timeout

[Michael]

I see this query timeout issue quite often.  I have a 4 system sql 
replication ring though, so it just moves onto the next one and keeps 
humming.  not sure what's causing the timeout though.

On 20/11/12 04:33 PM, Heikki Vatiainen wrote:
> On 11/20/2012 02:27 PM, Ricardo Martinez wrote:
>> Is there a way to mark the DB SQL as down in the configuration file, maybe
>> with a PostHook? Or something like that?
> Currently DB query timeout can not be trapped with a hook. Have you had
> problems with the DB timing out queries while still allowing connections?
>
> I'd like to know how common this problem is.
>
> Thanks,
> Heikki
>
>
>> Regards,
>> Ricardo.-
>>
>> -Mensaje original-
>> De: Ricardo Martinez [mailto:rmarti...@redvoiss.net]
>> Enviado el: lunes, 19 de noviembre de 2012 18:50
>> Para: 'Heikki Vatiainen'; 'radiator@open.com.au'
>> Asunto: RE: [RADIATOR] SQL Timeout
>>
>> There is also other post about the same issue :
>>
>> http://www.open.com.au/pipermail/radiator/2011-April/017237.html
>>
>>
>>
>> -Mensaje original-
>> De: Ricardo Martinez [mailto:rmarti...@redvoiss.net] Enviado el: lunes, 19
>> de noviembre de 2012 18:36
>> Para: 'Heikki Vatiainen'; 'radiator@open.com.au'
>> Asunto: RE: [RADIATOR] SQL Timeout
>>
>> Is there another more safe way to do the BackOff.  What I'm trying to do
>> is when a SQLquery is Timeout by Radiator mark the server as "down" and do
>> the next AuthBy Clause.
>> I saw a pair of question about the same issue near 2002 :
>> http://www.open.com.au/pipermail/radiator/2002-October/005289.html
>>
>> Please help me here.
>>
>> I'm using :
>> Radiator 4.9
>> perl, v5.10.1 (*) built for x86_64-linux-thread-multi DBI : 1 .622
>> DBD:mysql  4.022
>>
>> Regards,
>> Ricardo.-
>>
>>
>> -Mensaje original-
>> De: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] En
>> nombre de Heikki Vatiainen Enviado el: lunes, 19 de noviembre de 2012
>> 18:21
>> Para: radiator@open.com.au
>> Asunto: Re: [RADIATOR] SQL Timeout
>>
>> On 11/19/2012 10:47 PM, Ricardo Martinez wrote:
>>
>>> Question : When it says ".Radiator will wait for when trying to
>>> contact the SQL server." this means that a */select/* is a CONTACT???
>> Hello Ricardo,
>>
>> there is a contact before the select. The contact succeeds but the
>> subsequent query (DELYREQ) times out. Since it was the query that returned
>> error and not the contact just before it, FailureBackoffTime is not
>> triggered.
>>
>>> So, I don't understand why the Radiator is not doing the Backoff.
>> If you make the DB contact to block, for example using iptables to drop
>> traffic destined to the DB, it will then time out the connection attempt.
>> When this happens you will see it start the backoff timer.
>>
>> Thanks,
>> Heikki
>>
>> --
>> Heikki Vatiainen
>>
>> Radiator: the most portable, flexible and configurable RADIUS server
>> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
>> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER
>> etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
>> ___
>> radiator mailing list
>> radiator@open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>>
>
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

[Heikki Vatiainen]

On 11/20/2012 02:27 PM, Ricardo Martinez wrote:
> Is there a way to mark the DB SQL as down in the configuration file, maybe
> with a PostHook? Or something like that?

Currently DB query timeout can not be trapped with a hook. Have you had
problems with the DB timing out queries while still allowing connections?

I'd like to know how common this problem is.

Thanks,
Heikki


> Regards,
> Ricardo.-
> 
> -Mensaje original-
> De: Ricardo Martinez [mailto:rmarti...@redvoiss.net]
> Enviado el: lunes, 19 de noviembre de 2012 18:50
> Para: 'Heikki Vatiainen'; 'radiator@open.com.au'
> Asunto: RE: [RADIATOR] SQL Timeout
> 
> There is also other post about the same issue :
> 
> http://www.open.com.au/pipermail/radiator/2011-April/017237.html
> 
> 
> 
> -Mensaje original-
> De: Ricardo Martinez [mailto:rmarti...@redvoiss.net] Enviado el: lunes, 19
> de noviembre de 2012 18:36
> Para: 'Heikki Vatiainen'; 'radiator@open.com.au'
> Asunto: RE: [RADIATOR] SQL Timeout
> 
> Is there another more safe way to do the BackOff.  What I'm trying to do
> is when a SQLquery is Timeout by Radiator mark the server as "down" and do
> the next AuthBy Clause.
> I saw a pair of question about the same issue near 2002 :
> http://www.open.com.au/pipermail/radiator/2002-October/005289.html
> 
> Please help me here.
> 
> I'm using :
> Radiator 4.9
> perl, v5.10.1 (*) built for x86_64-linux-thread-multi DBI : 1 .622
> DBD:mysql  4.022
> 
> Regards,
> Ricardo.-
> 
> 
> -Mensaje original-
> De: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] En
> nombre de Heikki Vatiainen Enviado el: lunes, 19 de noviembre de 2012
> 18:21
> Para: radiator@open.com.au
> Asunto: Re: [RADIATOR] SQL Timeout
> 
> On 11/19/2012 10:47 PM, Ricardo Martinez wrote:
> 
>> Question : When it says ".Radiator will wait for when trying to
>> contact the SQL server." this means that a */select/* is a CONTACT???
> 
> Hello Ricardo,
> 
> there is a contact before the select. The contact succeeds but the
> subsequent query (DELYREQ) times out. Since it was the query that returned
> error and not the contact just before it, FailureBackoffTime is not
> triggered.
> 
>> So, I don't understand why the Radiator is not doing the Backoff.
> 
> If you make the DB contact to block, for example using iptables to drop
> traffic destined to the DB, it will then time out the connection attempt.
> When this happens you will see it start the backoff timer.
> 
> Thanks,
> Heikki
> 
> --
> Heikki Vatiainen 
> 
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
> TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER
> etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
> 


-- 
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

[Ricardo Martinez]

Is there a way to mark the DB SQL as down in the configuration file, maybe
with a PostHook? Or something like that?

Regards,
Ricardo.-

-Mensaje original-
De: Ricardo Martinez [mailto:rmarti...@redvoiss.net]
Enviado el: lunes, 19 de noviembre de 2012 18:50
Para: 'Heikki Vatiainen'; 'radiator@open.com.au'
Asunto: RE: [RADIATOR] SQL Timeout

There is also other post about the same issue :

http://www.open.com.au/pipermail/radiator/2011-April/017237.html



-Mensaje original-
De: Ricardo Martinez [mailto:rmarti...@redvoiss.net] Enviado el: lunes, 19
de noviembre de 2012 18:36
Para: 'Heikki Vatiainen'; 'radiator@open.com.au'
Asunto: RE: [RADIATOR] SQL Timeout

Is there another more safe way to do the BackOff.  What I'm trying to do
is when a SQLquery is Timeout by Radiator mark the server as "down" and do
the next AuthBy Clause.
I saw a pair of question about the same issue near 2002 :
http://www.open.com.au/pipermail/radiator/2002-October/005289.html

Please help me here.

I'm using :
Radiator 4.9
perl, v5.10.1 (*) built for x86_64-linux-thread-multi DBI : 1 .622
DBD:mysql  4.022

Regards,
Ricardo.-


-Mensaje original-
De: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] En
nombre de Heikki Vatiainen Enviado el: lunes, 19 de noviembre de 2012
18:21
Para: radiator@open.com.au
Asunto: Re: [RADIATOR] SQL Timeout

On 11/19/2012 10:47 PM, Ricardo Martinez wrote:

> Question : When it says ".Radiator will wait for when trying to
> contact the SQL server." this means that a */select/* is a CONTACT???

Hello Ricardo,

there is a contact before the select. The contact succeeds but the
subsequent query (DELYREQ) times out. Since it was the query that returned
error and not the contact just before it, FailureBackoffTime is not
triggered.

> So, I don't understand why the Radiator is not doing the Backoff.

If you make the DB contact to block, for example using iptables to drop
traffic destined to the DB, it will then time out the connection attempt.
When this happens you will see it start the backoff timer.

Thanks,
Heikki

--
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER
etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

[Ricardo Martinez]

There is also other post about the same issue :

http://www.open.com.au/pipermail/radiator/2011-April/017237.html



-Mensaje original-
De: Ricardo Martinez [mailto:rmarti...@redvoiss.net]
Enviado el: lunes, 19 de noviembre de 2012 18:36
Para: 'Heikki Vatiainen'; 'radiator@open.com.au'
Asunto: RE: [RADIATOR] SQL Timeout

Is there another more safe way to do the BackOff.  What I'm trying to do
is when a SQLquery is Timeout by Radiator mark the server as "down" and do
the next AuthBy Clause.
I saw a pair of question about the same issue near 2002 :
http://www.open.com.au/pipermail/radiator/2002-October/005289.html

Please help me here.

I'm using :
Radiator 4.9
perl, v5.10.1 (*) built for x86_64-linux-thread-multi DBI : 1 .622
DBD:mysql  4.022

Regards,
Ricardo.-


-Mensaje original-
De: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] En
nombre de Heikki Vatiainen Enviado el: lunes, 19 de noviembre de 2012
18:21
Para: radiator@open.com.au
Asunto: Re: [RADIATOR] SQL Timeout

On 11/19/2012 10:47 PM, Ricardo Martinez wrote:

> Question : When it says ".Radiator will wait for when trying to
> contact the SQL server." this means that a */select/* is a CONTACT???

Hello Ricardo,

there is a contact before the select. The contact succeeds but the
subsequent query (DELYREQ) times out. Since it was the query that returned
error and not the contact just before it, FailureBackoffTime is not
triggered.

> So, I don't understand why the Radiator is not doing the Backoff.

If you make the DB contact to block, for example using iptables to drop
traffic destined to the DB, it will then time out the connection attempt.
When this happens you will see it start the backoff timer.

Thanks,
Heikki

--
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER
etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

[Ricardo Martinez]

Is there another more safe way to do the BackOff.  What I'm trying to do
is when a SQLquery is Timeout by Radiator mark the server as "down" and do
the next AuthBy Clause.
I saw a pair of question about the same issue near 2002 :
http://www.open.com.au/pipermail/radiator/2002-October/005289.html

Please help me here.

I'm using :
Radiator 4.9
perl, v5.10.1 (*) built for x86_64-linux-thread-multi
DBI : 1 .622
DBD:mysql  4.022

Regards,
Ricardo.-


-Mensaje original-
De: radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] En
nombre de Heikki Vatiainen
Enviado el: lunes, 19 de noviembre de 2012 18:21
Para: radiator@open.com.au
Asunto: Re: [RADIATOR] SQL Timeout

On 11/19/2012 10:47 PM, Ricardo Martinez wrote:

> Question : When it says ".Radiator will wait for when trying to
> contact the SQL server." this means that a */select/* is a CONTACT???

Hello Ricardo,

there is a contact before the select. The contact succeeds but the
subsequent query (DELYREQ) times out. Since it was the query that returned
error and not the contact just before it, FailureBackoffTime is not
triggered.

> So, I don't understand why the Radiator is not doing the Backoff.

If you make the DB contact to block, for example using iptables to drop
traffic destined to the DB, it will then time out the connection attempt.
When this happens you will see it start the backoff timer.

Thanks,
Heikki

--
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER
etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

[Heikki Vatiainen]

On 11/19/2012 10:47 PM, Ricardo Martinez wrote:

> Question : When it says “…Radiator will wait for when trying to contact
> the SQL server…” this means that a */select/* is a CONTACT???

Hello Ricardo,

there is a contact before the select. The contact succeeds but the
subsequent query (DELYREQ) times out. Since it was the query that
returned error and not the contact just before it, FailureBackoffTime is
not triggered.

> So, I don’t understand why the Radiator is not doing the Backoff.

If you make the DB contact to block, for example using iptables to drop
traffic destined to the DB, it will then time out the connection
attempt. When this happens you will see it start the backoff timer.

Thanks,
Heikki

-- 
Heikki Vatiainen 

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

[Ricardo Martinez]

I’m doing 3 or even 4 querys for each one and keeps connecting to the mySQL
server and not doing the BackOff.



The Timeout parameter seems to be very clear about the behavior :

*5.31.4 Timeout*

This optional parameter specifies a timeout interval in seconds that
Radiator will wait

for when trying to contact the SQL server specified by DBAuth. If the
server does not

respond within the Timeout period, Radiator will consider the SQL server to
be failed,

and will stop trying to contact the SQL server until the FailureBackoffTime
is expired.

Defaults to 60 seconds.



Question : When it says “…Radiator will wait for when trying to contact the
SQL server…” this means that a *select* is a CONTACT???



So, I don’t understand why the Radiator is not doing the Backoff.

Any ideas?





Identifier AuthFailover

RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueUntilAccept



DBSourcedbi:mysql:prueba:127.0.0.1:3306

DBUsername  radius

DBAuth  radiator



Timeout 2

FailureBackoffTime  60

SQLRetries  1



AuthSelect call DELAYREQ;

AuthColumnDef 0, SIP-AVP, reply







Filename /usr/src/Radiator-4.9/users_tranum











Ricardo.-
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

[Michael]

I think you would have to query a 2nd time within 60 seconds in order to 
see the BackOff in the log.



On 19/11/12 02:44 PM, Ricardo Martinez wrote:


Hello Michael.

I have modified the AuthByPolicy fro mContinueWhileIgnore for

And now it jumps to the second AuthBy, but is not marking the DB as 
fail (and therefor doing the Backooff Time), this is the log.


What I’m doing wrong?

Mon Nov 19 16:41:05 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 34896 

Code:   Access-Request

Identifier: 112

Authentic: <31><23>t<202><197><247>5<185><138><147><198>*<22><184><216>x

Attributes:

User-Name = "sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>"


Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82 
<mailto:sip%3A0212345678@10.0.0.82>"


Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>"


NAS-Port = 0

NAS-IP-Address = 10.0.0.82

Mon Nov 19 16:41:05 2012: DEBUG: Handling request with Handler 
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', 
Identifier 'AuthFailover'


Mon Nov 19 16:41:05 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:41:05 2012: DEBUG:  Deleting session for 
sip:557100050994@10.0.0.86 <mailto:sip%3A557100050994@10.0.0.86>, 
10.0.0.82, 0


Mon Nov 19 16:41:05 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:41:05 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:41:05 2012: DEBUG: Query is: 'call DELAYREQ;':

Mon Nov 19 16:41:07 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:09 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL looks for match with 
sip:557100050994 [sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>]


Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL REJECT: No such user: 
sip:557100050994 [sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>]


Mon Nov 19 16:41:09 2012: DEBUG: Query is: 'call DELAYREQ;':

Mon Nov 19 16:41:11 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:13 2012: ERR: Execute failed for 'call DELAYREQ;': 
SQL Timeout


Mon Nov 19 16:41:13 2012: DEBUG: AuthBy SQL result: REJECT, No such user

Mon Nov 19 16:41:13 2012: DEBUG: Handling with Radius::AuthFILE:

Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE looks for match with 
sip:557100050994 [sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>]


Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE ACCEPT: : 
sip:557100050994 [sip:557100050994@10.0.0.86 
<mailto:sip%3A557100050994@10.0.0.86>]


Mon Nov 19 16:41:13 2012: DEBUG: AuthBy FILE result: ACCEPT,

Mon Nov 19 16:41:13 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:41:13 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 34896 

Code:   Access-Accept

Identifier: 112

Authentic:  @<165><188><181>;<242>-<251><184><200>q<174>`<239><24>k

Attributes:

SIP-AVP = "tranum:sip:0212345678@10.0.0.82 
<mailto:tranum%3Asip%3A0212345678@10.0.0.82>"


SIP-AVP = "channels:1"

Thanks,
Ricardo.-

*De:*Michael [mailto:ri...@vianet.ca <mailto:ri...@vianet.ca>]
*Enviado el:* lunes, 19 de noviembre de 2012 16:28
*Para:* Ricardo Martinez
*CC:* radiator@open.com.au <mailto:radiator@open.com.au>
*Asunto:* Re: [RADIATOR] SQL Timeout

looks like your first AuthBy SQL is answering accept.  is this maybe 
because you don't have any 'check' options at all?  Then if accept, 
never process the AuthBy FILE because of ContunueWhileIgnore.


For example, maybe you need at least one check option:
AuthColumnDef   1, Encrypted-Password, check

Not exactly sure though.



On 19/11/12 02:07 PM, Ricardo Martinez wrote:

Hello,

I’m trying to Backoff an SQL query to my database whenever a timeout 
happened.  I have the next configuration in my radius_auth.cfg :




RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSource
dbi:mysql:prueba:127.0.0.1:3306 <http://127.0.0.1:3306>


DBUsername  radius

DBAuth  radiator

Timeout 2

FailureBackoffTime  60

SQLRetries  2

NoDefault

AuthSelect call DELAYREQ;

AuthColumnDef 0, SIP-AVP, reply





Filename /usr/src/Radiator-4.9/us

Re: [RADIATOR] SQL Timeout

[Ricardo Martinez]

I miss the change : ContinueWhileIgnore for ContinueWhileReject



*De:* Michael [mailto:ri...@vianet.ca]
*Enviado el:* lunes, 19 de noviembre de 2012 16:28
*Para:* Ricardo Martinez
*CC:* radiator@open.com.au
*Asunto:* Re: [RADIATOR] SQL Timeout



looks like your first AuthBy SQL is answering accept.  is this maybe
because you don't have any 'check' options at all?  Then if accept, never
process the AuthBy FILE because of ContunueWhileIgnore.

For example, maybe you need at least one check option:
AuthColumnDef   1, Encrypted-Password, check

Not exactly sure though.



On 19/11/12 02:07 PM, Ricardo Martinez wrote:

Hello,

I’m trying to Backoff an SQL query to my database whenever a timeout
happened.  I have the next configuration in my radius_auth.cfg :





RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSourcedbi:mysql:prueba:127.0.0.1:3306

DBUsername  radius

DBAuth  radiator



Timeout 2

FailureBackoffTime  60

SQLRetries  2



NoDefault

AuthSelect call DELAYREQ;



AuthColumnDef 0, SIP-AVP, reply







Filename /usr/src/Radiator-4.9/users_tranum











The procedure DELAYREQ() in my mysql DB sleep for 5 seconds and return a
column.

This is the log for a Request to this Handler:



Mon Nov 19 16:03:33 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 36336 

Code:   Access-Request

Identifier: 96

Authentic:  h<29><217>d<218>=<220>!<200><191><170><148><2>.~^

Attributes:

User-Name = "sip:557100050994@10.0.0.86"

Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82"

Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86"

NAS-Port = 0

NAS-IP-Address = 10.0.0.82



Mon Nov 19 16:03:33 2012: DEBUG: Handling request with Handler
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', Identifier ''

Mon Nov 19 16:03:33 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:03:33 2012: DEBUG:  Deleting session for
sip:557100050994@10.0.0.86, 10.0.0.82, 0

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthGROUP:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Query is: 'call DELAYREQ;':



(2 seconds delay)



Mon Nov 19 16:03:35 2012: ERR: getOneRow timed out

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL looks for match with
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL ACCEPT: : sip:557100050994[
sip:557100050994@10.0.0.86]

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthGROUP:  result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: AuthBy GROUP result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:03:35 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 36336 

Code:   Access-Accept

Identifier: 96

Authentic:  M,<1><152><137><23>?<135><233>IA<137>-<14><30><11>

Attributes:

SIP-AVP = "avion"





I was expecting if the DB take too much time to answer it failover to the
second AuthBy.  Maybe I’m doing something wrong?

Can someone help me here?



Regards,

Ricardo.-




___

radiator mailing list

radiator@open.com.au

http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] SQL Timeout

[Ricardo Martinez]

Hello Michael.

I have modified the AuthByPolicy fro mContinueWhileIgnore for



And now it jumps to the second AuthBy, but is not marking the DB as fail
(and therefor doing the Backooff Time), this is the log.

What I’m doing wrong?



Mon Nov 19 16:41:05 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 34896 

Code:   Access-Request

Identifier: 112

Authentic:  <31><23>t<202><197><247>5<185><138><147><198>*<22><184><216>x

Attributes:

User-Name = "sip:557100050994@10.0.0.86"

Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82"

Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86"

NAS-Port = 0

NAS-IP-Address = 10.0.0.82



Mon Nov 19 16:41:05 2012: DEBUG: Handling request with Handler
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', Identifier
'AuthFailover'

Mon Nov 19 16:41:05 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:41:05 2012: DEBUG:  Deleting session for
sip:557100050994@10.0.0.86, 10.0.0.82, 0

Mon Nov 19 16:41:05 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:41:05 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:41:05 2012: DEBUG: Query is: 'call DELAYREQ;':

Mon Nov 19 16:41:07 2012: ERR: Execute failed for 'call DELAYREQ;': SQL
Timeout

Mon Nov 19 16:41:09 2012: ERR: Execute failed for 'call DELAYREQ;': SQL
Timeout

Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL looks for match with
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL REJECT: No such user:
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:41:09 2012: DEBUG: Query is: 'call DELAYREQ;':

Mon Nov 19 16:41:11 2012: ERR: Execute failed for 'call DELAYREQ;': SQL
Timeout

Mon Nov 19 16:41:13 2012: ERR: Execute failed for 'call DELAYREQ;': SQL
Timeout

Mon Nov 19 16:41:13 2012: DEBUG: AuthBy SQL result: REJECT, No such user

Mon Nov 19 16:41:13 2012: DEBUG: Handling with Radius::AuthFILE:

Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE looks for match with
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE ACCEPT: :
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:41:13 2012: DEBUG: AuthBy FILE result: ACCEPT,

Mon Nov 19 16:41:13 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:41:13 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 34896 

Code:   Access-Accept

Identifier: 112

Authentic:  @<165><188><181>;<242>-<251><184><200>q<174>`<239><24>k

Attributes:

SIP-AVP = "tranum:sip:0212345678@10.0.0.82"

SIP-AVP = "channels:1"



Thanks,
Ricardo.-



*De:* Michael [mailto:ri...@vianet.ca]
*Enviado el:* lunes, 19 de noviembre de 2012 16:28
*Para:* Ricardo Martinez
*CC:* radiator@open.com.au
*Asunto:* Re: [RADIATOR] SQL Timeout



looks like your first AuthBy SQL is answering accept.  is this maybe
because you don't have any 'check' options at all?  Then if accept, never
process the AuthBy FILE because of ContunueWhileIgnore.

For example, maybe you need at least one check option:
AuthColumnDef   1, Encrypted-Password, check

Not exactly sure though.



On 19/11/12 02:07 PM, Ricardo Martinez wrote:

Hello,

I’m trying to Backoff an SQL query to my database whenever a timeout
happened.  I have the next configuration in my radius_auth.cfg :





RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSourcedbi:mysql:prueba:127.0.0.1:3306

DBUsername  radius

DBAuth  radiator



Timeout 2

FailureBackoffTime  60

SQLRetries  2



NoDefault

AuthSelect call DELAYREQ;



AuthColumnDef 0, SIP-AVP, reply







Filename /usr/src/Radiator-4.9/users_tranum











The procedure DELAYREQ() in my mysql DB sleep for 5 seconds and return a
column.

This is the log for a Request to this Handler:



Mon Nov 19 16:03:33 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 36336 

Code:   Access-Request

Identifier: 96

Authentic:  h<29><217>d<218>=<220>!<200><191><170><148><2>.~^

Attributes:

User-Name = "sip:557100050994@10.0.0.86"

Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82

Re: [RADIATOR] SQL Timeout

[Michael]

looks like your first AuthBy SQL is answering accept.  is this maybe 
because you don't have any 'check' options at all?  Then if accept, 
never process the AuthBy FILE because of ContunueWhileIgnore.


For example, maybe you need at least one check option:
AuthColumnDef   1, Encrypted-Password, check

Not exactly sure though.



On 19/11/12 02:07 PM, Ricardo Martinez wrote:


Hello,

I'm trying to Backoff an SQL query to my database whenever a timeout 
happened.  I have the next configuration in my radius_auth.cfg :




RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSource
dbi:mysql:prueba:127.0.0.1:3306 


DBUsername  radius

DBAuth  radiator

Timeout 2

FailureBackoffTime  60

SQLRetries  2

NoDefault

AuthSelect call DELAYREQ;

AuthColumnDef 0, SIP-AVP, reply





Filename /usr/src/Radiator-4.9/users_tranum







The procedure DELAYREQ() in my mysql DB sleep for 5 seconds and return 
a column.


This is the log for a Request to this Handler:

Mon Nov 19 16:03:33 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 36336 

Code:   Access-Request

Identifier: 96

Authentic:  h<29><217>d<218>=<220>!<200><191><170><148><2>.~^

Attributes:

User-Name = "sip:557100050994@10.0.0.86 
"


Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82 
"


Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86 
"


NAS-Port = 0

NAS-IP-Address = 10.0.0.82

Mon Nov 19 16:03:33 2012: DEBUG: Handling request with Handler 
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', 
Identifier ''


Mon Nov 19 16:03:33 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:03:33 2012: DEBUG:  Deleting session for 
sip:557100050994@10.0.0.86 , 
10.0.0.82, 0


Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthGROUP:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Query is: 'call DELAYREQ;':

(2 seconds delay)

Mon Nov 19 16:03:35 2012: ERR: getOneRow timed out

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL looks for match with 
sip:557100050994 [sip:557100050994@10.0.0.86 
]


Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL ACCEPT: : 
sip:557100050994 [sip:557100050994@10.0.0.86 
]


Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthGROUP:  result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: AuthBy GROUP result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:03:35 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 36336 

Code:   Access-Accept

Identifier: 96

Authentic:  M,<1><152><137><23>?<135><233>IA<137>-<14><30><11>

Attributes:

SIP-AVP = "avion"

I was expecting if the DB take too much time to answer it failover to 
the second AuthBy.  Maybe I'm doing something wrong?


Can someone help me here?

Regards,

Ricardo.-



___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

[RADIATOR] SQL Timeout

[Ricardo Martinez]

Hello,

I’m trying to Backoff an SQL query to my database whenever a timeout
happened.  I have the next configuration in my radius_auth.cfg :





RewriteUsername s/^([^@]+).*/$1/



AuthByPolicy ContinueWhileIgnore



DBSourcedbi:mysql:prueba:127.0.0.1:3306

DBUsername  radius

DBAuth  radiator



Timeout 2

FailureBackoffTime  60

SQLRetries  2



NoDefault

AuthSelect call DELAYREQ;



AuthColumnDef 0, SIP-AVP, reply







Filename /usr/src/Radiator-4.9/users_tranum











The procedure DELAYREQ() in my mysql DB sleep for 5 seconds and return a
column.

This is the log for a Request to this Handler:



Mon Nov 19 16:03:33 2012: DEBUG: Packet dump:

*** Received from 10.0.0.82 port 36336 

Code:   Access-Request

Identifier: 96

Authentic:  h<29><217>d<218>=<220>!<200><191><170><148><2>.~^

Attributes:

User-Name = "sip:557100050994@10.0.0.86"

Service-Type = SIP-Caller-AVPs

Called-Station-Id = "sip:0212345678@10.0.0.82"

Sip-Uri-User = "0212345678"

Calling-Station-Id = "sip:557100050994@10.0.0.86"

NAS-Port = 0

NAS-IP-Address = 10.0.0.82



Mon Nov 19 16:03:33 2012: DEBUG: Handling request with Handler
'NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs', Identifier ''

Mon Nov 19 16:03:33 2012: DEBUG: Rewrote user name to sip:557100050994

Mon Nov 19 16:03:33 2012: DEBUG:  Deleting session for
sip:557100050994@10.0.0.86, 10.0.0.82, 0

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthGROUP:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Handling with Radius::AuthSQL:

Mon Nov 19 16:03:33 2012: DEBUG: Query is: 'call DELAYREQ;':



(2 seconds delay)



Mon Nov 19 16:03:35 2012: ERR: getOneRow timed out

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL looks for match with
sip:557100050994 [sip:557100050994@10.0.0.86]

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL ACCEPT: : sip:557100050994
[sip:557100050994@10.0.0.86]

Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthGROUP:  result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: AuthBy GROUP result: ACCEPT,

Mon Nov 19 16:03:35 2012: DEBUG: Access accepted for sip:557100050994

Mon Nov 19 16:03:35 2012: DEBUG: Packet dump:

*** Sending to 10.0.0.82 port 36336 

Code:   Access-Accept

Identifier: 96

Authentic:  M,<1><152><137><23>?<135><233>IA<137>-<14><30><11>

Attributes:

SIP-AVP = "avion"





I was expecting if the DB take too much time to answer it failover to the
second AuthBy.  Maybe I’m doing something wrong?

Can someone help me here?



Regards,

Ricardo.-
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: (RADIATOR) SQL Timeout?

[Hugh Irvine]

Hello Griff -

The first thing to check is the MySQL logs to see what is happening  
with the database.

Then you should probably turn on LogMicroseconds (requires Time-HiRes  
from CPAN) to see how long the queries are taking and what is happening  
when the problem occurs. It sounds like there is some large processing  
job that is tying up the database server every 3 hours.

And as usual, a complete copy of the configuration file (no secrets)  
and a trace 4 debug are needed to say any more.

regards

Hugh


On Wednesday, October 23, 2002, at 02:08 AM, Griff Hamlin wrote:

Hello,

I've noticed that about every 3 hours, I get an error message in my
logfile:

Tue Oct 22 02:03:03 2002: ERR: do failed for 'insert into dialupusage
  (username, session_id, router_ip, date, session_time, ip_address,
phone)
  values
  ('level3', '123410-22', '209.244.125.132', '2002-10-22
2:2:53', '0', '65.56.213.14', '9876543210')': SQL Timeout

and whenever I get this message, my server stops authenticating fast
enough. What's odd, is that if I run radpwtst and try to do a test
authentication, I'll get no reply after seeing this message until I
restart the radius server. But if I 'tail -f' my logfile, I see people
being authenticated, it's just getting to them maybe a minute or more
after the request comes in. Basically, the server gets behind in the
event it gets one of the SQL Timeout errors. My first question is, what
would cause that error, and secondly, why does it hang up Radiator?

The part of my radius.cfg file that handles accounting is as follows:

  RewriteUsername s/^([^@]+).*/$1/

  # Hook for using correct termination field and some logging
  PreAuthHook file:"/etc/raddb/accounting.hook"

  
AuthByPolicy ContinueUntilIgnore


  DBSourcedbi:mysql:localdialup
  DBUsername  %{GlobalVar:DbUser}
  DBAuth  %{GlobalVar:DbPass}

  AccountingTable dialupusage
  AccountingStopsOnly
  Timeout 5
  FailureBackoffTime 20
  AcctColumnDef username, %U, formatted
  AcctColumnDef session_id, %{Acct-Session-Id}%m-%d, formatted
  AcctColumnDef router_ip, %c, formatted
  AcctColumnDef date, %f-%g-%i %j:%k:%p, formatted
  AcctColumnDef session_time, %{Acct-Session-Time}, formatted
  AcctColumnDef ip_address, %{Framed-IP-Address}, formatted
  AcctColumnDef phone, %{Calling-Station-Id}, formatted
  AcctColumnDef terminate_cause, %{Term-Cause}, formatted


  DBSource%{GlobalVar:DbServer}
  DBUsername  %{GlobalVar:DbUser}
  DBAuth  %{GlobalVar:DbPass}
  AccountingStopsOnly
  Timeout 5
  FailureBackoffTime 20

  AcctSQLStatement update users set
prepaid_timeleft=prepaid_timeleft-0%{Acct-Session-Time} where
(prepay='true')&&(username='%U')

  AcctSQLStatement delete from online where
(((nasidentifier='%c')&&(nasport='%{NAS- 
Port}'))||((username='%n')&&(callingid='%{Calling-Station-Id}')))

 # SQL
   # Group
  AccountingHandled




Griff Hamlin, III
Quik Internet

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



NB: I am travelling this week, so there may be delays in our  
correspondence.

--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

(RADIATOR) SQL Timeout?

[Griff Hamlin]

Hello,

I've noticed that about every 3 hours, I get an error message in my
logfile:

Tue Oct 22 02:03:03 2002: ERR: do failed for 'insert into dialupusage
  (username, session_id, router_ip, date, session_time, ip_address,
phone)
  values
  ('level3', '123410-22', '209.244.125.132', '2002-10-22
2:2:53', '0', '65.56.213.14', '9876543210')': SQL Timeout

and whenever I get this message, my server stops authenticating fast
enough. What's odd, is that if I run radpwtst and try to do a test
authentication, I'll get no reply after seeing this message until I
restart the radius server. But if I 'tail -f' my logfile, I see people
being authenticated, it's just getting to them maybe a minute or more
after the request comes in. Basically, the server gets behind in the
event it gets one of the SQL Timeout errors. My first question is, what
would cause that error, and secondly, why does it hang up Radiator?

The part of my radius.cfg file that handles accounting is as follows:

  RewriteUsername s/^([^@]+).*/$1/

  # Hook for using correct termination field and some logging
  PreAuthHook file:"/etc/raddb/accounting.hook"

  
AuthByPolicy ContinueUntilIgnore


  DBSourcedbi:mysql:localdialup
  DBUsername  %{GlobalVar:DbUser}
  DBAuth  %{GlobalVar:DbPass}

  AccountingTable dialupusage
  AccountingStopsOnly
  Timeout 5
  FailureBackoffTime 20
  AcctColumnDef username, %U, formatted
  AcctColumnDef session_id, %{Acct-Session-Id}%m-%d, formatted
  AcctColumnDef router_ip, %c, formatted
  AcctColumnDef date, %f-%g-%i %j:%k:%p, formatted
  AcctColumnDef session_time, %{Acct-Session-Time}, formatted
  AcctColumnDef ip_address, %{Framed-IP-Address}, formatted
  AcctColumnDef phone, %{Calling-Station-Id}, formatted
  AcctColumnDef terminate_cause, %{Term-Cause}, formatted


  DBSource%{GlobalVar:DbServer}
  DBUsername  %{GlobalVar:DbUser}
  DBAuth  %{GlobalVar:DbPass}
  AccountingStopsOnly
  Timeout 5
  FailureBackoffTime 20

  AcctSQLStatement update users set
prepaid_timeleft=prepaid_timeleft-0%{Acct-Session-Time} where
(prepay='true')&&(username='%U')

  AcctSQLStatement delete from online where
(((nasidentifier='%c')&&(nasport='%{NAS-Port}'))||((username='%n')&&(callingid='%{Calling-Station-Id}')))

 # SQL
   # Group
  AccountingHandled




Griff Hamlin, III
Quik Internet

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: (RADIATOR) SQL Timeout vs SQL "Could not Connect"

[Hugh Irvine]

Hello Chris -

It sounds like Perl is crashing for some reason.

Can you run radiusd from the command line and see what is printed as 
the error message from Perl?

	perl radiusd -foreground -log_stdout -config_file .

regards

Hugh


On Monday, October 21, 2002, at 11:17 PM, Chris Cronje wrote:

Hi Hugh

If I'm not mistaken, we are using:

Perl Version 5.6.1
DBI - Version 1.30
DBD - Oracle version 1.12
Oracle Version 9i

Running on Red Hat Linux 7.3 on Intel Platform.

By "shut down immediately" I mean the following:

Radiator displays this message in the logfile:


Mon Oct 21 14:11:22 2002: ERR: do failed for 'delete from RADONLINE
where NASIDENTIFIER='196.2.129.13' and NASPORT=0': SQL Timeout


Immediately after this radiusd is not running as a process anymore. I 
dont see any additional errors or anything, radiusd is just not there 
anymore.

Thanks

Chris


-Original Message-
From: Hugh Irvine [mailto:hugh@;open.com.au]
Sent: 21 October 2002 02:51
To: Chris Cronje
Cc: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) SQL Timeout vs SQL "Could not Connect"



Hello Chris -

Could you please clarify what you mean by "shuts down immediately"?

And could you also please send me all the details regarding
hardware/software platform, versions of Perl, DBI, DBD, Oracle, etc.
Radiator should back off from the database for the specified time and
then try to reconnect.

regards

Hugh


On Monday, October 21, 2002, at 10:33 PM, Chris Cronje wrote:

Hi There

(Radiator 3.3.1)
I have a question about the Timeout and FailureBackoffTime settings
used for SQL connections. Specifically for the Sessiondatabase
configuration I am using below:


DBSourcedbi:Oracle:TEST
DBUsername  radiator
DBAuth  radiator
Timeout 3
FailureBackoffTime 60




If there is no existing SQL connection and Radiator cannot connect to
the SQL Database at all, a "Could not connect" message is generated
and Radiator backs off for 60 seconds as specified:



Mon Oct 21 14:09:50 2002: DEBUG: Packet dump:
*** Received from 196.2.129.13 port 1572 
Code:   Access-Request
Identifier: 0
Authentic:1035202501
Attributes:
User-Name = "modtest"
User-Password = "Z?<201>1<188><142>+<159>c<190>O+<21>M<180>t"

Mon Oct 21 14:09:50 2002: DEBUG: Handling request with Handler 
'Realm='
Mon Oct 21 14:09:53 2002: ERR: Could not connect to SQL database with
DBI->connect dbi:Oracle:TEST, radiator, radiator: timeout at
/usr/lib/perl5/site_perl/5.6.1/Radius/Util.pm line 519.

Mon Oct 21 14:09:53 2002: ERR: Could not connect to any SQL database.
Request is ignored. Backing off for 60 seconds




If there is an existing SQL session and a network failure occurs,
Radiator generates an "SQL Timeout" message, as opposed to the "Could
not connect" from above. In this case, Radiator does not seem to do
the Failure Backoff, in fact it actually shuts down immediately after
the SQL Timeout error:




Mon Oct 21 14:11:19 2002: DEBUG: Packet dump:
*** Received from 196.2.129.13 port 1582 
Code:   Access-Request
Identifier: 10
Authentic:1035202591
Attributes:
User-Name = "modtest"
User-Password =
"{<225>.<213><171>y<223><175><249><24>d<7>)<135><130>/"

Mon Oct 21 14:11:19 2002: DEBUG: Handling request with Handler 
'Realm='
Mon Oct 21 14:11:19 2002: DEBUG:  Deleting session for modtest,
196.2.129.13,
Mon Oct 21 14:11:19 2002: DEBUG: do query is: delete from RADONLINE
where NASIDENTIFIER='196.2.129.13' and NASPORT=0

Mon Oct 21 14:11:22 2002: ERR: do failed for 'delete from RADONLINE
where NASIDENTIFIER='196.2.129.13' and NASPORT=0': SQL Timeout



Is this the way it is supposed to be or should the FailureBackoffTime
work for both "Could Not Connect" and "SQL Timeout" conditions ?



Kind Regards

Chris Cronje
 
Give your child an unfair advantage with M-Web Learning.  To join,
call 08600 32 000 or go to http://join.mweb.co.za

M-Web – JUST LIKE THAT
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.



NB: I am travelling this week, so there may be delays in our
correspondence.

--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
&

RE: (RADIATOR) SQL Timeout when purging ACCOUNTING table

[Kitabjian, Dave]

My experience with such things is that it's a database contention problem:
the process of purging the table can easily (for Sql Server) escalate to a
table-lock, blocking any further Insert attempts.

I had to write a routine that would drop into a loop and delete one row at a
time, referring to that row exclusively by its Primary Key. That way, the
DBMS could find the row using the table index, and a table lock was hence
not necessary. This worked for me.

Another thing to consider is that the purge could simply be pegging the CPU
on the DB server (we've seen this, too). This is a lot easier to check: use
"top" on Unix or else Task Manager in NT.

Dave

> -Original Message-
> From: Janet N. del Mundo [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 13, 2001 5:16 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: (RADIATOR) SQL Timeout when purging ACCOUNTING table
> 
> 
> Hi Hugh,
> 
> The missedaccounting file contained just the accounting stop records. 
> Yes, I waited for about 30 mins. and authentication requests 
> started to
> be rejected.  That's when I had to restart Radiator.  What can I do to
> not interrupt the users authentication?  Would it make any 
> difference if
> I use just a regular flat file, and not the 'AcctFailedLog...' feature
> to capture start and stop records?
> 
> Thanks,
> Janet
> 
> Hugh Irvine wrote:
> > 
> > Hello Janet -
> > 
> > What data is contained in the AcctFailedLogFileName file? 
> Did it actually
> > catch the accounting data? Notice that this will only catch 
> accounting stops
> > as sessions end, and as the debug shows, Radiator will not retry the
> > connection for 10 minutes (600 seconds) - did you wait that 
> long to see if it
> > would re-establish?
> > 
> > regards
> > 
> > Hugh
> > 
> > On Tuesday 13 March 2001 15:58, Janet N. del Mundo wrote:
> > > Hi everyone,
> > >
> > > Radiator still times out connecting to the SQL server 
> when we do a month
> > > end purge of old accounting data and our users are unable to
> > > authenticate.  I thought by using the 
> 'AcctFailedLogFileName' feature,
> > > the accounting data would default to this flat file and 
> not interrupt
> > > user authentication.  However, we just did a purge of old 
> data and I had
> > > to restart Radiator when the purge process was done.  
> What can I do to
> > > avoid this problem?
> > >
> > > log file:
> > > -
> > > Mon Mar 12 07:40:12 2001: ERR: Could not connect to SQL 
> database with
> > > DBI->connect dbi:ODBC:, x, x:  
> [OpenLink][ODBC]exceeded
> > > maximum number of allowed connections (SQL-08004)
> > > [OpenLink][ODBC]Connection rejected by data source (SQL-08004)
> > > [OpenLink][ODBC]exceeded maximum number of allowed connections
> > > (SQL-08004)
> > > [OpenLink][ODBC]Connection rejected by data source 
> (SQL-08004)(DBD:
> > > db_login/SQLConnect err=-1)
> > > Mon Mar 12 07:40:12 2001: ERR: Could not connect to any 
> SQL database.
> > > Request is ignored. Backing off for 600 sec
> > > onds
> > >
> > > config file:
> > > 
> > > 
> > > Identifier SQL
> > > DBSource dbi:ODBC:x
> > > DBUsername x
> > > DBAuth x
> > >
> > > AuthSelect select Password, Expiration, SimUse, \
> > > IdleTime, SessionTime, StaticIP \
> > > from USERS where IDENTIFIER = '%n' AND 
> STATUS != 'C'
> > >
> > > AuthColumnDef 1, Expiration, check
> > > AuthColumnDef 2, Simultaneous-Use, check
> > > AuthColumnDef 3, Idle-Timeout, reply
> > > AuthColumnDef 4, Session-Timeout, reply
> > > AuthColumnDef 5, Framed-IP-Address, reply
> > >
> > > AccountingTable ACCOUNTING
> > >
> > > AcctColumnDef   IDENTIFIER,User-Name
> > > AcctColumnDef   
> TIME_STAMP,Timestamp,formatted-date,'%m-%d-%Y
> > > %H:%M:%S'
> > > AcctColumnDef   DURATION,Acct-Session-Time,integer
> > > AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
> > > AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
> > > #AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets,integer
> > > #AcctColumnDef   
> ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
> > > AcctC

Re: (RADIATOR) SQL Timeout when purging ACCOUNTING table

[Hugh Irvine]

Hello Janet -

On Wednesday 14 March 2001 09:15, Janet N. del Mundo wrote:
> Hi Hugh,
>
> The missedaccounting file contained just the accounting stop records.
> Yes, I waited for about 30 mins. and authentication requests started to
> be rejected.  That's when I had to restart Radiator.  What can I do to
> not interrupt the users authentication?  Would it make any difference if
> I use just a regular flat file, and not the 'AcctFailedLog...' feature
> to capture start and stop records?
>

It won't make any difference what file you use, as the problem appears to be 
with the OpenLink ODBC driver, or with the database (although I suspect the 
former).

BTW - if monthly (long) runs are causing a problem, why not do a daily run at 
the quietest time of your day (probably around 4am)? You really shouldn't be 
doing any heavy processing on the database during your busy times.

I have forwarded your mail to Mike for his comments.

regards

Hugh


-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.


===
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.

Re: (RADIATOR) SQL Timeout when purging ACCOUNTING table

[Janet N. del Mundo]

Hi Hugh,

The missedaccounting file contained just the accounting stop records. 
Yes, I waited for about 30 mins. and authentication requests started to
be rejected.  That's when I had to restart Radiator.  What can I do to
not interrupt the users authentication?  Would it make any difference if
I use just a regular flat file, and not the 'AcctFailedLog...' feature
to capture start and stop records?

Thanks,
Janet

Hugh Irvine wrote:
> 
> Hello Janet -
> 
> What data is contained in the AcctFailedLogFileName file? Did it actually
> catch the accounting data? Notice that this will only catch accounting stops
> as sessions end, and as the debug shows, Radiator will not retry the
> connection for 10 minutes (600 seconds) - did you wait that long to see if it
> would re-establish?
> 
> regards
> 
> Hugh
> 
> On Tuesday 13 March 2001 15:58, Janet N. del Mundo wrote:
> > Hi everyone,
> >
> > Radiator still times out connecting to the SQL server when we do a month
> > end purge of old accounting data and our users are unable to
> > authenticate.  I thought by using the 'AcctFailedLogFileName' feature,
> > the accounting data would default to this flat file and not interrupt
> > user authentication.  However, we just did a purge of old data and I had
> > to restart Radiator when the purge process was done.  What can I do to
> > avoid this problem?
> >
> > log file:
> > -
> > Mon Mar 12 07:40:12 2001: ERR: Could not connect to SQL database with
> > DBI->connect dbi:ODBC:, x, x:  [OpenLink][ODBC]exceeded
> > maximum number of allowed connections (SQL-08004)
> > [OpenLink][ODBC]Connection rejected by data source (SQL-08004)
> > [OpenLink][ODBC]exceeded maximum number of allowed connections
> > (SQL-08004)
> > [OpenLink][ODBC]Connection rejected by data source (SQL-08004)(DBD:
> > db_login/SQLConnect err=-1)
> > Mon Mar 12 07:40:12 2001: ERR: Could not connect to any SQL database.
> > Request is ignored. Backing off for 600 sec
> > onds
> >
> > config file:
> > 
> > 
> > Identifier SQL
> > DBSource dbi:ODBC:x
> > DBUsername x
> > DBAuth x
> >
> > AuthSelect select Password, Expiration, SimUse, \
> > IdleTime, SessionTime, StaticIP \
> > from USERS where IDENTIFIER = '%n' AND STATUS != 'C'
> >
> > AuthColumnDef 1, Expiration, check
> > AuthColumnDef 2, Simultaneous-Use, check
> > AuthColumnDef 3, Idle-Timeout, reply
> > AuthColumnDef 4, Session-Timeout, reply
> > AuthColumnDef 5, Framed-IP-Address, reply
> >
> > AccountingTable ACCOUNTING
> >
> > AcctColumnDef   IDENTIFIER,User-Name
> > AcctColumnDef   TIME_STAMP,Timestamp,formatted-date,'%m-%d-%Y
> > %H:%M:%S'
> > AcctColumnDef   DURATION,Acct-Session-Time,integer
> > AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
> > AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
> > #AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets,integer
> > #AcctColumnDef   ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
> > AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
> > AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause
> > #AcctColumnDef   NASIDENTIFIER,NAS-Identifier
> > AcctColumnDef   NASIDENTIFIER,NAS-IP-Address
> > AcctColumnDef   NASPORT,NAS-Port,integer
> > AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
> > AcctColumnDef   CONNECTSPEED,Connect-Info
> > AcctColumnDef   CONNECTSPEED,USR-Connect-Speed
> > AcctColumnDef   CALLERID,Calling-Station-Id
> > AcctColumnDef   POPID,Called-Station-Id
> >
> > # You can arrange to log accounting to a file if the
> > # SQL insert fails with AcctFailedLogFileName
> > # That way you could recover from a broken SQL
> > # server
> > AcctLogFileFormat %{User-Name};%m-%d-%Y
> > %H:%M:%S;%{Acct-Session-Time};%{Acct-Status-Type};\
> > %{Acct-Delay-Time};%{Acct-Session-Id};%{Acct-Terminate-Cause};\
> > %{NAS-IP-Address};%{NAS-Port};%{Framed-IP-Address};%{Connect-Info};\
> > %{USR-Connect-Speed};%{Calling-Station-Id};%{Called-Station-Id}
> >
> > AcctFailedLogFileName %D/missedaccounting.%y%m%d
> >
> > 
> >
> > Thank you,
> > Janet
> 
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.

-- 
_
Janet del Mundo 
Internet Administrator, Startec Global Communications
135 Chalan Santo Papa   Agana, Guam  96910
Email: [EMAIL PROTECTED]
Phone: (671) 475-6879
Fax  : (671) 477-6054

===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe ra

Re: (RADIATOR) SQL Timeout when purging ACCOUNTING table

[Hugh Irvine]

Hello Janet -

What data is contained in the AcctFailedLogFileName file? Did it actually 
catch the accounting data? Notice that this will only catch accounting stops 
as sessions end, and as the debug shows, Radiator will not retry the 
connection for 10 minutes (600 seconds) - did you wait that long to see if it 
would re-establish?

regards

Hugh


On Tuesday 13 March 2001 15:58, Janet N. del Mundo wrote:
> Hi everyone,
>
> Radiator still times out connecting to the SQL server when we do a month
> end purge of old accounting data and our users are unable to
> authenticate.  I thought by using the 'AcctFailedLogFileName' feature,
> the accounting data would default to this flat file and not interrupt
> user authentication.  However, we just did a purge of old data and I had
> to restart Radiator when the purge process was done.  What can I do to
> avoid this problem?
>
> log file:
> -
> Mon Mar 12 07:40:12 2001: ERR: Could not connect to SQL database with
> DBI->connect dbi:ODBC:, x, x:  [OpenLink][ODBC]exceeded
> maximum number of allowed connections (SQL-08004)
> [OpenLink][ODBC]Connection rejected by data source (SQL-08004)
> [OpenLink][ODBC]exceeded maximum number of allowed connections
> (SQL-08004)
> [OpenLink][ODBC]Connection rejected by data source (SQL-08004)(DBD:
> db_login/SQLConnect err=-1)
> Mon Mar 12 07:40:12 2001: ERR: Could not connect to any SQL database.
> Request is ignored. Backing off for 600 sec
> onds
>
> config file:
> 
> 
> Identifier SQL
> DBSource dbi:ODBC:x
> DBUsername x
> DBAuth x
>
> AuthSelect select Password, Expiration, SimUse, \
> IdleTime, SessionTime, StaticIP \
> from USERS where IDENTIFIER = '%n' AND STATUS != 'C'
>
> AuthColumnDef 1, Expiration, check
> AuthColumnDef 2, Simultaneous-Use, check
> AuthColumnDef 3, Idle-Timeout, reply
> AuthColumnDef 4, Session-Timeout, reply
> AuthColumnDef 5, Framed-IP-Address, reply
>
> AccountingTable ACCOUNTING
>
> AcctColumnDef   IDENTIFIER,User-Name
> AcctColumnDef   TIME_STAMP,Timestamp,formatted-date,'%m-%d-%Y
> %H:%M:%S'
> AcctColumnDef   DURATION,Acct-Session-Time,integer
> AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
> AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
> #AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets,integer
> #AcctColumnDef   ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
> AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
> AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause
> #AcctColumnDef   NASIDENTIFIER,NAS-Identifier
> AcctColumnDef   NASIDENTIFIER,NAS-IP-Address
> AcctColumnDef   NASPORT,NAS-Port,integer
> AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
> AcctColumnDef   CONNECTSPEED,Connect-Info
> AcctColumnDef   CONNECTSPEED,USR-Connect-Speed
> AcctColumnDef   CALLERID,Calling-Station-Id
> AcctColumnDef   POPID,Called-Station-Id
>
> # You can arrange to log accounting to a file if the
> # SQL insert fails with AcctFailedLogFileName
> # That way you could recover from a broken SQL
> # server
> AcctLogFileFormat %{User-Name};%m-%d-%Y
> %H:%M:%S;%{Acct-Session-Time};%{Acct-Status-Type};\
> %{Acct-Delay-Time};%{Acct-Session-Id};%{Acct-Terminate-Cause};\
> %{NAS-IP-Address};%{NAS-Port};%{Framed-IP-Address};%{Connect-Info};\
> %{USR-Connect-Speed};%{Calling-Station-Id};%{Called-Station-Id}
>
> AcctFailedLogFileName %D/missedaccounting.%y%m%d
>
> 
>
> Thank you,
> Janet

-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
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.

(RADIATOR) SQL Timeout when purging ACCOUNTING table

[Janet N. del Mundo]

Hi everyone,

Radiator still times out connecting to the SQL server when we do a month
end purge of old accounting data and our users are unable to
authenticate.  I thought by using the 'AcctFailedLogFileName' feature,
the accounting data would default to this flat file and not interrupt
user authentication.  However, we just did a purge of old data and I had
to restart Radiator when the purge process was done.  What can I do to
avoid this problem?

log file:
-
Mon Mar 12 07:40:12 2001: ERR: Could not connect to SQL database with
DBI->connect dbi:ODBC:, x, x:  [OpenLink][ODBC]exceeded
maximum number of allowed connections (SQL-08004)
[OpenLink][ODBC]Connection rejected by data source (SQL-08004)
[OpenLink][ODBC]exceeded maximum number of allowed connections
(SQL-08004)
[OpenLink][ODBC]Connection rejected by data source (SQL-08004)(DBD:
db_login/SQLConnect err=-1)
Mon Mar 12 07:40:12 2001: ERR: Could not connect to any SQL database.
Request is ignored. Backing off for 600 sec
onds

config file:


Identifier SQL
DBSource dbi:ODBC:x
DBUsername x
DBAuth x

AuthSelect select Password, Expiration, SimUse, \ 
IdleTime, SessionTime, StaticIP \
from USERS where IDENTIFIER = '%n' AND STATUS != 'C'

AuthColumnDef 1, Expiration, check
AuthColumnDef 2, Simultaneous-Use, check
AuthColumnDef 3, Idle-Timeout, reply
AuthColumnDef 4, Session-Timeout, reply
AuthColumnDef 5, Framed-IP-Address, reply

AccountingTable ACCOUNTING

AcctColumnDef   IDENTIFIER,User-Name
AcctColumnDef   TIME_STAMP,Timestamp,formatted-date,'%m-%d-%Y
%H:%M:%S'
AcctColumnDef   DURATION,Acct-Session-Time,integer
AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
#AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets,integer
#AcctColumnDef   ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause
#AcctColumnDef   NASIDENTIFIER,NAS-Identifier
AcctColumnDef   NASIDENTIFIER,NAS-IP-Address
AcctColumnDef   NASPORT,NAS-Port,integer
AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
AcctColumnDef   CONNECTSPEED,Connect-Info
AcctColumnDef   CONNECTSPEED,USR-Connect-Speed
AcctColumnDef   CALLERID,Calling-Station-Id
AcctColumnDef   POPID,Called-Station-Id

# You can arrange to log accounting to a file if the
# SQL insert fails with AcctFailedLogFileName
# That way you could recover from a broken SQL
# server
AcctLogFileFormat %{User-Name};%m-%d-%Y
%H:%M:%S;%{Acct-Session-Time};%{Acct-Status-Type};\
%{Acct-Delay-Time};%{Acct-Session-Id};%{Acct-Terminate-Cause};\
%{NAS-IP-Address};%{NAS-Port};%{Framed-IP-Address};%{Connect-Info};\
%{USR-Connect-Speed};%{Calling-Station-Id};%{Called-Station-Id}

AcctFailedLogFileName %D/missedaccounting.%y%m%d



Thank you,
Janet

-- 
_
Janet del Mundo 
Internet Administrator, Startec Global Communications
135 Chalan Santo Papa   Agana, Guam  96910
Email: [EMAIL PROTECTED]

===
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.

Re: (RADIATOR) Sql Timeout!

[Hugh Irvine]

Hello Faez -

On Fri, 24 Nov 2000, Faez Itrat wrote:
> Hi,
>  I have just started evaluating radiator and am using its demo version
> at the mement and my users database is created on Remote Oracle
> database...am facing two problems..firstly i'm getting sql  timeout and
> secondly the radius process just dies out after every request and i have
> to restart itfollowing is my Trace 4 Debug outputit is taking
> around 14-15 seconds between  'Handling with radius:SQLAuth' and i think
> this is causing problems...i'm running my radius on sparc machine...can
> somebody help me in this regard ?
> 

Have a look at this item in the FAQ:

http://www.open.com.au/radiator/faq.html#58

hth

Hugh


-- 
Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence. 


===
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.

(RADIATOR) Sql Timeout!

[Faez Itrat]

Hi,
 I have just started evaluating radiator and am using its demo version
at the mement and my users database is created on Remote Oracle
database...am facing two problems..firstly i'm getting sql  timeout and
secondly the radius process just dies out after every request and i have
to restart itfollowing is my Trace 4 Debug outputit is taking
around 14-15 seconds between  'Handling with radius:SQLAuth' and i think
this is causing problems...i'm running my radius on sparc machine...can
somebody help me in this regard ?



Fri Nov 24 15:19:23 2000: DEBUG: Handling request with Handler
'Realm=DEFAULT'
Fri Nov 24 15:19:23 2000: DEBUG:  Deleting session for xx,
203.63.154.1, 1234
Fri Nov 24 15:19:23 2000: DEBUG: Handling with Radius::AuthSQL
Fri Nov 24 15:19:39 2000: DEBUG: Handling with Radius::AuthSQL
Fri Nov 24 15:19:39 2000: DEBUG: Query is: select password from account
where lo
gin_name='xx'


best regards,
Faez



===
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.

Re: (RADIATOR) SQL Timeout (Oracle 8.1.6+Radiator 2.16.3)

[Hugh Irvine]

Hello Alexey -

On Sat, 23 Sep 2000, Alexey A. Shavaldin wrote:
> Hello !
> 
> On Sat, 23 Sep 2000, Hugh Irvine wrote:
> 
> > Could you send us a bit more detail on your hardware and software plaforms and
> > the Radiator and database setups (in terms of what software is running on what
> > host)? Also, have you tried altering the Timeout and FailureBackoffTime
> > parameters in the AuthBy SQL clause? Normally, Radiator will wait 60 seconds
> > for a reply to an SQL query, then it will not try to reconnect for a further
> > 600 seconds (10 minutes).
> 

> > > 
> > > Trace 4 log:
> > > 
> > > Fri Sep 22 20:05:32 2000: ERR: do failed for 'insert into RADONLINE ( USERNAME, 
> > > REALM, NASIDENTIFIER, NASPORT,  ACCTSESSIONID, TIME_STAMP, FRAMEDIPADDRESS,
> > > NASPORTTYPE, SERVICETYPE, CalledStationId, CallingStationId ) values ( 'x',
> > >  '' , 'yyy.yyy.yyy.yyy' , nvl('48',0), 'CA86', SYSDATE, '', 'Async',
> > > 'Framed-User', '38', '' )'': SQL Timeout
> > > 
> > > Besides, I've found such a thing: Oracle refuses to shut down by command, when
> > > Radiator is running. Oracle reports: waiting for unclosed connections. When I
> > > stop Radiator, Oracle shuts down correctly.
> > > 
> > > Thirdly, when I make radpwtst test FREQUENTLY for some test user, first test
> > > works OK for Access-Request,Start and Stop, but the second, which goes right
> > > adter the first, reports OK for "Access-Request" and "Accounting Stop", but No
> > > reply for Start:
> 

It may be the case that Radiator is incorrectly interpreting errors being
reported by the database. Can you have a look at the logs prior to the SQL
Timeout shown above, to see whether there have been any other errors reported?
If so, can you please send us a copy of all of the SQL errors up to and
including the last one.

thanks

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.

Re: (RADIATOR) SQL Timeout (Oracle 8.1.6+Radiator 2.16.3)

[Alexey A. Shavaldin]

Hello !

On Sat, 23 Sep 2000, Hugh Irvine wrote:

> Could you send us a bit more detail on your hardware and software plaforms and
> the Radiator and database setups (in terms of what software is running on what
> host)? Also, have you tried altering the Timeout and FailureBackoffTime
> parameters in the AuthBy SQL clause? Normally, Radiator will wait 60 seconds
> for a reply to an SQL query, then it will not try to reconnect for a further
> 600 seconds (10 minutes).

We have a server station (Dual PIII-500,RAID5 array,392Mb RAM) running Linux
RedHat 6.2 (kernel version 2.2.16 with patches for i2o subsystem for RAID5
array and for reiserfs, whole base system works on ext2 partition), Oracle8i
(8.1.6) with a single instance and a single database,Radiator 2.16.3.
FailureBackoffTime is set to 30, TimeOut - defaults to 60 seconds. Part of my
AuthBy SQL clause:



Identifier  AcctStop
FailureBackoffTime 30
DBSourcedbi:Oracle:auth3
DBUsername   
DBAuth  
AuthSelect
AccountingStopsOnly
AcctSQLStatement insert into radacct ( \
RadAcctId, \
AcctSessionId, \
UserName, \
Realm, \   
..

 

> > On Sat, 23 Sep 2000, Alexey A. Shavaldin wrote:
> > I've got a problem with SQL Timeout, when using Oracle 8.1.6 and Radiator
> > 2.16.3.  The fact is that authorization works OK for first several users, they
> > login and work OK, but then authorization for next users just hangs. Radiator
> > reports SQL Timeout, and the problem is usually solved after that by
> > stopping/starting Radiator again. After that authorization works OK for the
> > next 20-30 users. Is that really the problem with Radiator (as I have to reload
> > it) or with Oracle. 
> > 
> > Trace 4 log:
> > 
> > Fri Sep 22 20:05:32 2000: ERR: do failed for 'insert into RADONLINE ( USERNAME, 
> > REALM, NASIDENTIFIER, NASPORT,  ACCTSESSIONID, TIME_STAMP, FRAMEDIPADDRESS,
> > NASPORTTYPE, SERVICETYPE, CalledStationId, CallingStationId ) values ( 'x',
> >  '' , 'yyy.yyy.yyy.yyy' , nvl('48',0), 'CA86', SYSDATE, '', 'Async',
> > 'Framed-User', '38', '' )'': SQL Timeout
> > 
> > Besides, I've found such a thing: Oracle refuses to shut down by command, when
> > Radiator is running. Oracle reports: waiting for unclosed connections. When I
> > stop Radiator, Oracle shuts down correctly.
> > 
> > Thirdly, when I make radpwtst test FREQUENTLY for some test user, first test
> > works OK for Access-Request,Start and Stop, but the second, which goes right
> > adter the first, reports OK for "Access-Request" and "Accounting Stop", but No
> > reply for Start:

-- 
With regards,
Alexey A. Shavaldin  [EMAIL PROTECTED]

System Administrator
of Kraft-S, JSC

===
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.

Re: (RADIATOR) SQL Timeout (Oracle 8.1.6+Radiator 2.16.3)

[Hugh Irvine]

Hello Alexey -

Could you send us a bit more detail on your hardware and software plaforms and
the Radiator and database setups (in terms of what software is running on what
host)? Also, have you tried altering the Timeout and FailureBackoffTime
parameters in the AuthBy SQL clause? Normally, Radiator will wait 60 seconds
for a reply to an SQL query, then it will not try to reconnect for a further
600 seconds (10 minutes).

thanks

Hugh

On Sat, 23 Sep 2000, Alexey A. Shavaldin wrote:
> Hello !
> 
> I've got a problem with SQL Timeout, when using Oracle 8.1.6 and Radiator
> 2.16.3.  The fact is that authorization works OK for first several users, they
> login and work OK, but then authorization for next users just hangs. Radiator
> reports SQL Timeout, and the problem is usually solved after that by
> stopping/starting Radiator again. After that authorization works OK for the
> next 20-30 users. Is that really the problem with Radiator (as I have to reload
> it) or with Oracle. 
> 
> Trace 4 log:
> 
> Fri Sep 22 20:05:32 2000: ERR: do failed for 'insert into RADONLINE ( USERNAME, 
> REALM, NASIDENTIFIER, NASPORT,  ACCTSESSIONID, TIME_STAMP, FRAMEDIPADDRESS,
> NASPORTTYPE, SERVICETYPE, CalledStationId, CallingStationId ) values ( 'x',
>  '' , 'yyy.yyy.yyy.yyy' , nvl('48',0), 'CA86', SYSDATE, '', 'Async',
> 'Framed-User', '38', '' )'': SQL Timeout
> 
> Besides, I've found such a thing: Oracle refuses to shut down by command, when
> Radiator is running. Oracle reports: waiting for unclosed connections. When I
> stop Radiator, Oracle shuts down correctly.
> 
> Thirdly, when I make radpwtst test FREQUENTLY for some test user, first test
> works OK for Access-Request,Start and Stop, but the second, which goes right
> adter the first, reports OK for "Access-Request" and "Accounting Stop", but No
> reply for Start:
> 

-- 
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.

(RADIATOR) SQL Timeout (Oracle 8.1.6+Radiator 2.16.3)

[Alexey A. Shavaldin]

Hello !

I've got a problem with SQL Timeout, when using Oracle 8.1.6 and Radiator
2.16.3.  The fact is that authorization works OK for first several users, they
login and work OK, but then authorization for next users just hangs. Radiator
reports SQL Timeout, and the problem is usually solved after that by
stopping/starting Radiator again. After that authorization works OK for the
next 20-30 users. Is that really the problem with Radiator (as I have to reload
it) or with Oracle. 

Trace 4 log:

Fri Sep 22 20:05:32 2000: ERR: do failed for 'insert into RADONLINE ( USERNAME, 
REALM, NASIDENTIFIER, NASPORT,  ACCTSESSIONID, TIME_STAMP, FRAMEDIPADDRESS,
NASPORTTYPE, SERVICETYPE, CalledStationId, CallingStationId ) values ( 'x',
 '' , 'yyy.yyy.yyy.yyy' , nvl('48',0), 'CA86', SYSDATE, '', 'Async',
'Framed-User', '38', '' )'': SQL Timeout

Besides, I've found such a thing: Oracle refuses to shut down by command, when
Radiator is running. Oracle reports: waiting for unclosed connections. When I
stop Radiator, Oracle shuts down correctly.

Thirdly, when I make radpwtst test FREQUENTLY for some test user, first test
works OK for Access-Request,Start and Stop, but the second, which goes right
adter the first, reports OK for "Access-Request" and "Accounting Stop", but No
reply for Start:

First test:

sending Access-Request...
OK
sending Accounting-Request Start...
OK
sending Accounting-Request Stop...
OK 

Second test:

sending Access-Request...
OK
sending Accounting-Request Start...
No reply
sending Accounting-Request Stop...
OK

The fact is that when I make these test less frequently, every Request reports
OK.

I'll appreciate any help.
Thanks a lot.

-- 
With regards,
Alexey A. Shavaldin  [EMAIL PROTECTED]

System Administrator
of Kraft-S, JSC

===
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.

RE: (RADIATOR) SQL Timeout

[Hugh Irvine]

Hello Emin -

On Thu, 29 Jun 2000, Emin TAHRALI wrote:
> 
> 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?

When there is no reply to a query sent to the server.

> How does the Radioator communicate with SQL (Oracle) Server? (OK by using
> DBI and DBD but how?)

It opens a TCP connection to a particular port number where the SQL server is
listnening and sends and receives data streams which are the SQL queries and
responses.

> How does the Radiator understand, that the SQL server is down or
> unreachable?

If there is no reply to a query, or if the TCP port number cannot be opened or
re-opened after unexpectedly closing.

> For which packets does the Radiator looking for, to verify that the deletion
> process is OK?

It checks the return status for every DBI call.

> Is DELETE transaction commited right after the proccess, or is there any
> delay?
> 

There should not be any delay.

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.

RE: (RADIATOR) SQL Timeout

[Emin TAHRALI]

Title: RE: (RADIATOR) SQL Timeout





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.'),'dd.mm.')
> >=to_date(to_char(SYSDATE,'dd.mm.'),'dd.mm.') 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.

Re: (RADIATOR) SQL Timeout & SNMP Query

[Hugh Irvine]

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.'),'dd.mm.')
> >=to_date(to_char(SYSDATE,'dd.mm.'),'dd.mm.') 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.



===
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.

(RADIATOR) SQL Timeout & SNMP Query

[Emin TAHRALI]

Title: SQL Timeout & SNMP Query





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.


We guess, this problem occurs because of the SNMP query in one way or another, but it is not ceratin.
The cause of the problem can also be a deadlock in SQL or something else.


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.



Sun 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.'),'dd.mm.') >=to_date(to_char(SYSDATE,'dd.mm.'),'dd.mm.') OR EXPIREDATE IS NULL) AND subscribers.SESSIONFILTERID = sessionfilters.SESSIONFILTERID

.

(RADIATOR) SQL Timeout!

[Tuncay MARGILIC]

Title: SQL Timeout!







Hi all,


I am facing the SQL Timeout problem. We user Oracle 8i as the DB , Radiator 2.15. 


Hugh can you send me the conditions that Radiator sends SQL Tiemout message.



Also I need a debug patch that will give me a level 5 trace that will be activated when the SQL Timeout is happened.
Because I cannot use the trace 5 all the time. This effects the service performance.


Is that possible?



Tuncay

Re: (RADIATOR) SQL Timeout

[Hugh Irvine]

Hello Beth -

On Tue, 02 May 2000, Beth Morgan wrote:
> Hi all,
> 
> We are running Radiator 2.15, using mysqld  Ver 3.22.29 for
> freebsdelf3.3.  Every week or so I am having to reboot the machine when
> it stops wanting to authenticate because of a SQL timeout.  Here's what
> the log says:
> 
> --
> Mon May  1 16:15:18 2000: ERR: do failed for 'insert into RADUSAGE
> (USERNAME, TIME_STAMP, ACCTSTATUSTYPE, ACCTDELAYTIME,
> ACCTINPUTOCTETS, ACCTOUTPUTOCTETS, ACCTSESSIONID, ACCTSESSIONTIME,
> ACCTTERMINATECAUSE, FRAMEDIPADDRESS, NASIDENTIFIER, NASPORT, DNIS,
> CONNECTINFO) 
> values 
> ('mgentry', 957211998, 2, 0, 5870, 917, '100729031', 36,
> 1, '12.20.159.237', '12.4.96.42', 1538, '', '28800_BPS')': SQL Timeout
> 
> --
> 
> When I ps auxw, I can see that mysqld is running.
> 
> Has anyone run into this and know how I can go about resolving it?
> 

If it is a transient problem with the database, Radiator will try to reopen the
connection according to the SQL parameters in section 6.24 of the manual.

Have a look at sections 6.24.4 Timeout and 6.24.5 FailureBackoffTime.

> Also, is there any kind of monitoring software that anyone knows of that
> can check Radiator maybe every minute to see that it's running - and
> MySQL?  
> 

Some people use MRTG for this purpose. There is a sample configuration in the
FAQ: http://www.open.com.au/radiator/faq.html#50

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.

Re: (RADIATOR) SQL Timeout

[Danny Whitesel]

Beth,

Check out Netsaint at www.netsaint.org. I have it running here monitoring
quite an array of items from individual services to disk space. If something
goes down, it pages me via an alpha-numberic pager with a text description
of what is not responding as expected.

-Danny


-Original Message-
From: Beth Morgan <[EMAIL PROTECTED]>
To: Radiator Mailing List <[EMAIL PROTECTED]>
Date: Monday, May 01, 2000 6:20 PM
Subject: (RADIATOR) SQL Timeout


>Hi all,
>
>We are running Radiator 2.15, using mysqld  Ver 3.22.29 for
>freebsdelf3.3.  Every week or so I am having to reboot the machine when
>it stops wanting to authenticate because of a SQL timeout.  Here's what
>the log says:
>
>--
>Mon May  1 16:15:18 2000: ERR: do failed for 'insert into RADUSAGE
>(USERNAME, TIME_STAMP, ACCTSTATUSTYPE, ACCTDELAYTIME,
>ACCTINPUTOCTETS, ACCTOUTPUTOCTETS, ACCTSESSIONID, ACCTSESSIONTIME,
>ACCTTERMINATECAUSE, FRAMEDIPADDRESS, NASIDENTIFIER, NASPORT, DNIS,
>CONNECTINFO)
>values
>('mgentry', 957211998, 2, 0, 5870, 917, '100729031', 36,
>1, '12.20.159.237', '12.4.96.42', 1538, '', '28800_BPS')': SQL Timeout
>
>--
>
>When I ps auxw, I can see that mysqld is running.
>
>Has anyone run into this and know how I can go about resolving it?
>
>Also, is there any kind of monitoring software that anyone knows of that
>can check Radiator maybe every minute to see that it's running - and
>MySQL?
>
>Thanks,
>Beth
>
>===
>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.
>


===
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.

(RADIATOR) SQL Timeout

[Beth Morgan]

Hi all,

We are running Radiator 2.15, using mysqld  Ver 3.22.29 for
freebsdelf3.3.  Every week or so I am having to reboot the machine when
it stops wanting to authenticate because of a SQL timeout.  Here's what
the log says:

--
Mon May  1 16:15:18 2000: ERR: do failed for 'insert into RADUSAGE
(USERNAME, TIME_STAMP, ACCTSTATUSTYPE, ACCTDELAYTIME,
ACCTINPUTOCTETS, ACCTOUTPUTOCTETS, ACCTSESSIONID, ACCTSESSIONTIME,
ACCTTERMINATECAUSE, FRAMEDIPADDRESS, NASIDENTIFIER, NASPORT, DNIS,
CONNECTINFO) 
values 
('mgentry', 957211998, 2, 0, 5870, 917, '100729031', 36,
1, '12.20.159.237', '12.4.96.42', 1538, '', '28800_BPS')': SQL Timeout

--

When I ps auxw, I can see that mysqld is running.

Has anyone run into this and know how I can go about resolving it?

Also, is there any kind of monitoring software that anyone knows of that
can check Radiator maybe every minute to see that it's running - and
MySQL?  

Thanks,
Beth

===
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.

Re: (RADIATOR) SQL timeout

[Hugh Irvine]

Hello Andrew -

On Wed, 29 Dec 1999, Andrew Kaplan wrote:
> I am still plagued with Radiator failing to authenticate.  We had problems
> today. The log shows a bunch of SQL timeout errors at the same time. Any
> idea as to what is the problem.
> 

If you are trying to authenticate from SQL and the database has problems and
timeouts, it is certain that Radiator will have a problem as it will wait for
the database to respond. You should either correct the problem with your
database or set up a secondary SQL server or perhaps an alternative source of
authentication information.

hth

Hugh


-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8,
NT, Rhapsody

===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: (RADIATOR) SQL timeout

[Ray Carpenter]

You could add a backup sql server and then specify another DBSource,
DBUsername, & DBAuth in your AuthBy.  Then if your sql server timesout
Radiator would switch to your backup and your users would still be able to
authenticate.

-Original Message-
From: Andrew Kaplan <[EMAIL PROTECTED]>
To: Radiator <[EMAIL PROTECTED]>
Date: Tuesday, December 28, 1999 7:23 PM
Subject: (RADIATOR) SQL timeout


>I am still plagued with Radiator failing to authenticate.  We had problems
>today. The log shows a bunch of SQL timeout errors at the same time. Any
>idea as to what is the problem.
>
>TIA,
>
>Andrew P. Kaplan, CNE, MCSE+Internet, MCT, CCNA, CCDA
>CyberShore, Inc. -- Premium Internet Services -- http://www.cshore.com
>
>Imagination is a quality given a man to compensate him for what he is not,
>and a sense of humor was provided to console him for who he
is.Oscar
>Wilde
>
>
>
>
>
>
> __o
>   _-\<,_
>..(_)/ (_)
>``
>
>
>
>
>===
>Archive at http://www.thesite.com.au/~radiator/
>To unsubscribe, email '[EMAIL PROTECTED]' with
>'unsubscribe radiator' in the body of the message.


===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Re: (RADIATOR) SQL timeout

[tom minchin]

On Tue, Dec 28, 1999 at 05:50:44PM -0500, Andrew Kaplan wrote:
> I am still plagued with Radiator failing to authenticate.  We had problems
> today. The log shows a bunch of SQL timeout errors at the same time. Any
> idea as to what is the problem.
> 

If it's a regular problem, perhaps leave Radiator running in debug 4 mode.

If Radiator reports an SQL timeout, it means that it couldn't query your
database to lookup users.

Ob: it would be nice if you could specify another AuthBy inside an AuthBy
SQL. This AuthBy would only be used if the SQL server failed (eg use a
flat file). I know you can do this by cascading AuthBys, but I couldn't
figure out how to do it when you already have a cascade of AuthBys already.

[EMAIL PROTECTED]

===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

(RADIATOR) SQL timeout

[Andrew Kaplan]

I am still plagued with Radiator failing to authenticate.  We had problems
today. The log shows a bunch of SQL timeout errors at the same time. Any
idea as to what is the problem.

TIA,

Andrew P. Kaplan, CNE, MCSE+Internet, MCT, CCNA, CCDA
CyberShore, Inc. -- Premium Internet Services -- http://www.cshore.com

Imagination is a quality given a man to compensate him for what he is not,
and a sense of humor was provided to console him for who he is.Oscar
Wilde






 __o
   _-\<,_
..(_)/ (_)
``




===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.