On Fri, Oct 8, 2021 at 2:35 PM Alan DeKok <aland@deployingradius.com> wrote:
Most callers of the function pass a "retry" option. That causes the function to immediately retry the connection request. The main caller which *doesn't* to rebind is the mod_conn_create() function, which tries to create the initial connection.
The fix might be as simple as changing the retry parameter in mod_conn_create() from "false" to "true". If that works, we can add it in.
I tried that during my debug process. However it results in a segmentation fault, since apparently the pool for the instance is NULL. Segfaults in this line: https://github.com/FreeRADIUS/freeradius-server/blob/c6f15c7ee66dc0473ef45e7... On Fri, Oct 8, 2021 at 2:35 PM Alan DeKok <aland@deployingradius.com> wrote:
On Oct 8, 2021, at 5:25 AM, Antonio Torres <antorres@redhat.com> wrote:
If we build the OpenLDAP package without the LDAP_USE_NON_BLOCKING_TLS flag, the issue disappears, so it is probably related to the async connection. I've seen there has been some work on the async LDAP connection process, but I'm not entirely sure whether it is related, and it is only in v4: https://github.com/FreeRADIUS/freeradius-server/pull/4240
We're moving v4 to be completely async, but that's unrelated to the v3 code.
I'm wondering whether FreeRADIUS needs to adapt to these changes or the issue is entirely on the OpenLDAP side. What do you think?
The code in v3 uses a function rlm_ldap_bind() to bind to LDAP. That function takes a "retry" parameter.
Most callers of the function pass a "retry" option. That causes the function to immediately retry the connection request. The main caller which *doesn't* to rebind is the mod_conn_create() function, which tries to create the initial connection.
The fix might be as simple as changing the retry parameter in mod_conn_create() from "false" to "true". If that works, we can add it in.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html