[RADIATOR] SQL Timeout
Ricardo Martinez
rmartinez at redvoiss.net
Mon Nov 19 13:44:06 CST 2012
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 at 10.0.0.86"
Service-Type = SIP-Caller-AVPs
Called-Station-Id = "sip:0212345678 at 10.0.0.82"
Sip-Uri-User = "0212345678"
Calling-Station-Id = "sip:557100050994 at 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 at 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 at 10.0.0.86]
Mon Nov 19 16:41:09 2012: DEBUG: Radius::AuthSQL REJECT: No such user:
sip:557100050994 [sip:557100050994 at 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 at 10.0.0.86]
Mon Nov 19 16:41:13 2012: DEBUG: Radius::AuthFILE ACCEPT: :
sip:557100050994 [sip:557100050994 at 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 at 10.0.0.82"
SIP-AVP = "channels:1"
Thanks,
Ricardo.-
*De:* Michael [mailto:ringo at vianet.ca]
*Enviado el:* lunes, 19 de noviembre de 2012 16:28
*Para:* Ricardo Martinez
*CC:* radiator at 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 :
<Handler NAS-IP-Address = 10.0.0.82, Service-Type = SIP-Caller-AVPs>
RewriteUsername s/^([^@]+).*/$1/
<AuthBy GROUP>
AuthByPolicy ContinueWhileIgnore
<AuthBy SQL>
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
</AuthBy>
<AuthBy FILE>
Filename /usr/src/Radiator-4.9/users_tranum
</AuthBy>
</AuthBy>
</Handler>
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 at 10.0.0.86"
Service-Type = SIP-Caller-AVPs
Called-Station-Id = "sip:0212345678 at 10.0.0.82"
Sip-Uri-User = "0212345678"
Calling-Station-Id = "sip:557100050994 at 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 at 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 at 10.0.0.86]
Mon Nov 19 16:03:35 2012: DEBUG: Radius::AuthSQL ACCEPT: : sip:557100050994[
sip:557100050994 at 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 at open.com.au
http://www.open.com.au/mailman/listinfo/radiator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20121119/54259e2c/attachment-0001.html
More information about the radiator
mailing list