limiting fail timeout for an LDAP module

Zenon Mousmoulas zmousm at noc.grnet.gr
Fri Feb 3 18:21:13 CET 2017


Hi,

I am working with a peculiar LDAP backend which, from time to time, will 
take upwards of 10 seconds to respond to a search request. I know that 
is what needs fixing, but let's say I have to live with it for now. 
There is a second LDAP backend which I can use a backup when the first 
one goes nuts. So I'm thinking let's setup two LDAP module instances and 
use them in a redundant group. For this to be usable for EAP 
authentication however, I need to make sure freeradius fails the first 
LDAP module within some (short) time limit. I have thus been trying to 
tweak the first LDAP module instance settings in order to achieve that.

After experimenting with these settings:

options.res_timeout
options.srv_timelimit
pool.start

I found that if I set pool.start=0 and, say, options.res_timeout=2 
freeradius reconnects (retrying the search once) and fails the module 
after a total of 4 seconds:

Fri Feb  3 18:29:43 2017 : Debug: (1) ldap_first_bad: Waiting for search 
result...
Fri Feb  3 18:29:44 2017 : Debug: Waking up in 0.4 seconds.
Fri Feb  3 18:29:44 2017 : Debug: Waking up in 0.7 seconds.
Fri Feb  3 18:29:45 2017 : Debug: Waking up in 1.1 seconds.
Fri Feb  3 18:29:45 2017 : Debug: rlm_ldap: Closing libldap handle 
0x7fa240000cb0
Fri Feb  3 18:29:45 2017 : Debug: rlm_ldap (ldap_first_bad): 
Reconnecting (0)
Fri Feb  3 18:29:45 2017 : Debug: rlm_ldap (ldap_first_bad): Connecting 
to ldaps://xxxxxxxx
Fri Feb  3 18:29:45 2017 : Debug: rlm_ldap (ldap_first_bad): New libldap 
handle 0x7fa238000da0
Fri Feb  3 18:29:45 2017 : Debug: rlm_ldap (ldap_first_bad): Waiting for 
bind result...
Fri Feb  3 18:29:45 2017 : Debug: rlm_ldap (ldap_first_bad): Bind 
successful
Fri Feb  3 18:29:45 2017 : WARNING: (1) ldap_first_bad: Search failed: 
Timed out while waiting for server to respond. Got new socket, 
retrying...
Fri Feb  3 18:29:45 2017 : Debug: (1) ldap_first_bad: Waiting for search 
result...
Fri Feb  3 18:29:46 2017 : Debug: Waking up in 1.6 seconds.
Fri Feb  3 18:29:47 2017 : Debug: rlm_ldap: Closing libldap handle 
0x7fa238000da0
Fri Feb  3 18:29:47 2017 : Debug: rlm_ldap (ldap_first_bad): 
Reconnecting (0)
Fri Feb  3 18:29:47 2017 : Debug: rlm_ldap (ldap_first_bad): Connecting 
to ldaps://xxxxxxxx
Fri Feb  3 18:29:47 2017 : Debug: rlm_ldap (ldap_first_bad): New libldap 
handle 0x7fa238000da0
Fri Feb  3 18:29:47 2017 : Debug: rlm_ldap (ldap_first_bad): Waiting for 
bind result...
Fri Feb  3 18:29:47 2017 : Debug: rlm_ldap (ldap_first_bad): Bind 
successful
Fri Feb  3 18:29:47 2017 : WARNING: (1) ldap_first_bad: Search failed: 
Timed out while waiting for server to respond. Got new socket, 
retrying...
Fri Feb  3 18:29:47 2017 : Debug: (1) ldap_first_bad: Waiting for search 
result...
Fri Feb  3 18:29:48 2017 : Debug: Waking up in 2.5 seconds.
Fri Feb  3 18:29:48 2017 : Error: (1) Ignoring duplicate packet from 
client localhost port 34423 - ID: 11 due to unfinished request in 
component authorize module ldap_first_bad
Fri Feb  3 18:29:48 2017 : Debug: Waking up in 1.9 seconds.
Fri Feb  3 18:29:49 2017 : Debug: rlm_ldap: Closing libldap handle 
0x7fa238000da0
Fri Feb  3 18:29:49 2017 : Debug: rlm_ldap (ldap_first_bad): 
Reconnecting (0)
Fri Feb  3 18:29:49 2017 : Debug: rlm_ldap (ldap_first_bad): Connecting 
to ldaps://xxxxxxxx
Fri Feb  3 18:29:49 2017 : Debug: rlm_ldap (ldap_first_bad): New libldap 
handle 0x7fa238000da0
Fri Feb  3 18:29:49 2017 : Debug: rlm_ldap (ldap_first_bad): Waiting for 
bind result...
Fri Feb  3 18:29:49 2017 : Debug: rlm_ldap (ldap_first_bad): Bind 
successful
Fri Feb  3 18:29:49 2017 : WARNING: (1) ldap_first_bad: Search failed: 
Timed out while waiting for server to respond. Got new socket, 
retrying...
Fri Feb  3 18:29:49 2017 : ERROR: (1) ldap_first_bad: Hit reconnection 
limit
Fri Feb  3 18:29:49 2017 : Debug: rlm_ldap (ldap_first_bad): Released 
connection (0)
Fri Feb  3 18:29:49 2017 : Info: rlm_ldap (ldap_first_bad): Need 1 more 
connections to reach 10 spares
Fri Feb  3 18:29:49 2017 : Info: rlm_ldap (ldap_first_bad): Opening 
additional connection (2), 1 of 30 pending slots used
Fri Feb  3 18:29:49 2017 : Debug: rlm_ldap (ldap_first_bad): Connecting 
to ldaps://xxxxxxxx
Fri Feb  3 18:29:49 2017 : Debug: rlm_ldap (ldap_first_bad): New libldap 
handle 0x7fa2380215b0
Fri Feb  3 18:29:50 2017 : Debug: rlm_ldap (ldap_first_bad): Waiting for 
bind result...
Fri Feb  3 18:29:50 2017 : Debug: rlm_ldap (ldap_first_bad): Bind 
successful
Fri Feb  3 18:29:50 2017 : Debug: (1)       modsingle[authorize]: 
returned from ldap_first_bad (rlm_ldap)
Fri Feb  3 18:29:50 2017 : Debug: (1)       [ldap_first_bad] = fail
Fri Feb  3 18:29:50 2017 : Debug: (1)       modsingle[authorize]: 
calling ldap_backup (rlm_ldap)

I am wondering if this is as good as it gets or if there are other 
things to tweak or to try, to get a shorter timeout in this particular 
case, perhaps avoiding the side effect of start=0 documented therein 
(Set to 0 to allow the server to start without the directory being 
available).

This is on freeradius 3.0.12.

Thanks for any insight,
Z.


More information about the Freeradius-Users mailing list