[RADIATOR] SQL Timeout

Ricardo Martinez rmartinez at redvoiss.net
Mon Nov 19 13:46:02 CST 2012


I miss the change : ContinueWhileIgnore for ContinueWhileReject



*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/41ca3d5a/attachment.html 


More information about the radiator mailing list