https://bugs.openldap.org/show_bug.cgi?id=9244
--- Comment #3 from Ryan Tandy ryan@openldap.org --- A few notes from investigation so far.
50b33cc6 is wrong and masked some issues. ENOTCONN is telling us that we're trying to send on the socket before it finished connecting - meaning we actually have a bug somewhere earlier. Solaris 10 is actually a better platform for testing this, because Linux just returns EAGAIN in this case. (Also noticed by others, e.g. https://lists.freebsd.org/pipermail/freebsd-bugs/2008-November/033159.html.)
Other patches by the same author are similar workarounds to issues that shouldn't happen - need to identify and fix the root cause. The changes to avoid sockets being set to blocking should all be unnecessary, because none of them should be reached until after the connection is established. (For example, I think ldap_int_start_tls shouldn't need to consider the async setting at all, only the timeout.)
ldap_int_check_async_open doesn't check the network timeout. The code that _does_ check it can't be reached before the connection is established, so as far as I can tell, the connect timeout is currently just ignored when async.
ldap_send_initial_request calls ldap_int_check_async_open(ld_defconn). But when chasing a referral, that's a different connection! Again, Linux masks this bug by returning EAGAIN, but on Solaris 10 I can see that the referral connection sends its Bind too early and gets ENOTCONN. That one should be an easy fix.