Closed antoniotorresm closed 2 years ago
This is fixed in the v3.0.x branch, and will be included in 3.0.26 when it is released.
Until then, just change the LDAP connection pool to use start = 0
Thanks for your quick reply, @alandekok. I've tried building from source and testing but unfortunately the issue persists. There was the commit 21d95b268b4cf56e75064898d83123825d673818 that partially addressed this but got reverted a few weeks later in d14f77ef797d537f309e73f2333bc1eaef8080ba.
Yes that patch caused deadlocks elsewhere IIRC. Does it work with start = 0
? That should arguably be the default in 99% of situations anyway, as otherwise when your LDAP server is down FreeRADIUS will entirely refuse to start up.
Setting start = 0
will allow FreeRADIUS to start, but the failure still shows when querying through radtest
. The LDAP server is running and TLS auth is working through ldapsearch
.
The debug output points to an error during SSL connect:
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL_connect:error in SSLv3/TLS write client hello
Setting LDAP_OPT_NETWORK_TIMEOUT
to -1 (which is the OpenLDAP default) when using start_tls = yes
will fix this, since it makes libldap use a blocking socket during the TLS start procedure. Doing this in combination with start = 0
guarantees FreeRADIUS to start even if the LDAP server is non-responsive.
What type of defect/bug is this?
Unexpected behaviour (obvious or verified by project member)
How can the issue be reproduced?
start_tls = yes
in ldap module configradiusd -X
Additional info:
ldapsearch
.Log output from the FreeRADIUS daemon
Relevant log output from client utilities
No response
Backtrace from LLDB or GDB
No response