On Fri, Oct 8, 2021 at 3:00 PM Alan DeKok <aland@deployingradius.com> wrote:
The short term solution is to just set "start=0" in the "pool" configuration of the LDAP module. *And* also set the retry parameter to "true". Along with some other changes (attached), that might work.
That worked. I have created a PR with the changes: https://github.com/FreeRADIUS/freeradius-server/pull/4266 On Fri, Oct 8, 2021 at 3:00 PM Alan DeKok <aland@deployingradius.com> wrote:
On Oct 8, 2021, at 8:45 AM, Antonio Torres <antorres@redhat.com> wrote:
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...
Ah, yes. The pool isn't set up yet. The solution is more complex, then.
What *should* happen is that the LDAP library returns a "partially open" connection. i.e. a connection which is partially bound, but which still needs to read/write more data. It looks like instead it returns *no* connection.
Which puts FreeRADIUS into a bit of a problem. If every operation (a) doesn't return any handle, and (b) returns "retry", then there's simply no way to say "continue connecting on partially open handle". And nothing will ever work.
The short term solution is to just set "start=0" in the "pool" configuration of the LDAP module. *And* also set the retry parameter to "true". Along with some other changes (attached), that might work.
If that helps, I can push the patch over.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html