EAP-TLS performance SQL backend bottleneck

[leopold]

Thank you very much Alan for your reply.
Let me please clarify the requirements.
EAP-TLS: 
- perform the needed SSL handshake, there are 11 messages exchanged and I do
not want to query SQL each time and it degrades performance.
- find the user/machine in SQL, compare check attributes and respond with
reply attributes based on SQL data. If SQL is down or some other SQL
connection failure then DO NOT RESPOND.
If user/machine is not found in SQL DB or check attributes do not match
reject, otherwise accept.

Your suggestion with sql.authorize in post-auth section "almost" works, the
only problem is we need not to respond when SQL is down. Because otherwise
RADIUS might respond with Access-Accept and won't send the needed reply
attributes when SQL is unavailable.
Could you please change the code if there is not other neat way around to
still use "do_not_respond" policy in post-auth section?
Maybe in event.c you could check if control is set not to respond and then
drop the packet?
Thanks again



Alan DeKok-2 wrote:
> 
> leopold wrote:
>> OK thanks Alan. I moved sql module call from "authorize" to "post-auth",
>> this
>> improves performance, but the behavior is different.
> 
>   List "sql.authorize" in the post-auth section.  Not "sql".
> 
>> Inside policy.conf we have "do_not_respond" policy and if SQL server is
>> down
>> we need to force server not to respond in "post-auth"
> 
>   The code currently sets the response packet type (accept / reject),
> and THEN calls the post-auth methods.
> 
>> Is there any limit where do_not_respond can be used?
> 
>   Yes.  It cannot be used in the post-auth section.
> 
>   It sounds like your requirements are somewhat contradictory.  You
> DON'T want it to query SQL for the EAP-TLS traffic, but you DO want it
> to ignore EAP-TLS  if the SQL database is down.
> 
>   If the SQL database is down, and you don't want the server to respond,
> then just bring the server down.  Write a simple shell script to poke
> the SQL server, and to re-start FreeRADIUS once the SQL server comes
> back up.
> 
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
> 
> 

-- 
View this message in context: http://www.nabble.com/EAP-TLS-performance-SQL-backend-bottleneck-tp25386668p25400465.html
Sent from the FreeRadius - User mailing list archive at Nabble.com.