FreeRADIUS Thread Behaviour

[Michael Ströder]

Alan DeKok wrote:
> On Oct 16, 2017, at 11:21 AM, Doug Wussler <doug.wussler at fsu.edu> wrote:
>> The motivation for looking into this is that I have occasions where freeradius
>> reports “Could not start TLS: Can't contact LDAP server”
>> which seems to only occur when a new thread fires up and tries to start TLS
>> to the LDAP server.
> 
> Because the OpenLDAP API is crappy.  There's no explicit "initialize"
> routine, so the OpenLDAP code has to guess, and can get it wrong.

What do you mean by "initialize" and "has to guess"?

Disclaimer: I did not look at FreeRADIUS code.

No news that OpenLDAP API (with its roots in RFC 1823) has real
deficiencies. Everybody involved agrees on that.

But most issues developers experience are caused by the lazy connect in
libldap: ldap_initialize() and friends do *not* to the LDAP server.
You have send the first LDAP operation to really connect and handle
connection errors *after* that.

In multi-threaded software with a persistent connection (pool) I usually
use a lock to ensure that ldap_initialize() and bind (simple or SASL)
were successfully done before the connection can be used by another
thread. That's also the reason why I usually avoid a code path with
anon-search-without-bind because I want to provoke a connect error with
an explicit bind right from the beginning.

This also might get tricky when the OpenLDAP server drops idle
connections or was simply restarted and your multi-threaded LDAP client
has to re-connect.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20171016/537ff223/attachment.bin>