Behavior of FreeRADIUS auth when SQL backend becomes inaccessible

[Arran Cudbard-Bell]

On 5 Mar 2014, at 10:52, Alan DeKok <aland at deployingradius.com> wrote:

> Patrick Wagner wrote:
>> However, if we start FR while  and subsequently shut down the SQL
>> instance, rlm_sql returns a fail, “SQL query error; rejecting user”, and
>> FR subsequently sends a REJECT response to any NAS request it receives,
>> which is not at all the behavior we’d like to see as it means that any
>> NAS querying this particular FR node will deny all requests instead of
>> retrying the request with another node.
> 
>  In 2.2.3, you can use the "do_not_respond" policy.
> 
> 	sql
> 	if (fail) {
> 		do_not_respond
> 		
> 	}
> 
>> Actually, FR's current behavior is a bit more irritating to us because
>> we need to use a custom huntgroup SQL query that we placed in an "update
>> request" section right before we (try to) query SQL for auth in the
>> "authorize" section, but instead of two times "fail" we get two
>> different error  codes from the two statements when SQL is unavailable:
>> 
>> -  "++ [request] returns notfound"
>> 
>> and later
>> 
>> - " ++[sql_localhost] returns fail"
> 
>  That's because the dynamic queries don't have a module failure code.
> Fixing that involves serious architectural changes.

They should do, ish. That was one of the fixes that went in before 3.0.0 was released.

xlats can return negative integers to indicate failure.

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140305/43474e02/attachment.pgp>