--- Comment #3 from Ryan Tandy <ryan(a)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.
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.
You are receiving this mail because:
You are on the CC list for the bug.