https://bugs.openldap.org/show_bug.cgi?id=9474
--- Comment #1 from Howard Chu <[email protected]> --- (In reply to Simon Pichugin from comment #0) > The description of my findings (take a note that these are OpenLDAP logs > that happen under the application that uses libldap): > > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_write: > want=610, written=610 > ... > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: > SSL_connect:SSLv3 flush data > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_read: want=5 > error=Interrupted system call > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: > SSL_connect:error in SSLv3 read finished A > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: > SSL_connect:error in SSLv3 read finished A > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS: can't connect: > . > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: > ldap_free_connection 1 1 > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_send_unbind > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ber_flush2: 7 bytes > to sd 23 > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 > 01 00 42 00 > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_write: want=7, > written=7 > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 > 01 01 42 00 > [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: > ldap_free_connection: actually freed > > So, 'error=Interrupted system call' is caught by this: > https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/ > tls2.c#L360 > https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblber/ > sockbuf.c#L829 > It is only the debug message that comes from the caller itself so we can see > what is passed to OpenSSL. > And 'Interrupted system call' is just an EINTR string representation. > > What we should do is to catch the error that OpenSSL returns to us after it > is interrupted. > > As we can see from the logs: > "libldap: TLS: can't connect: ." > This line returns nothing: > https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/ > tls2.c#L427 > So 'ld->ld_error' is set to empty value. > > If we go deeper into the 'tls_imp->ti_session_errmsg' call we can reach the > point where ERR_peek_error() is called: > https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/ > tls2.c#L416 > https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/ > tls_o.c#L563 > https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/ > tls_o.c#L569 > > In the conclusion: > ldap_install_tls() should return meaningful error code that would allow to > figure out a reason for the failure, especially network IO fail due to EITR. Sorry, your request is still vague. "Should return meaningful error code" - which error code are you asking to be returned? The EINTR is returned from the I/O layer to the TLS library, so it's up to the TLS library to give that back to libldap. If ERR_peek_error() gives us an empty string then there's nothing else for us to return. -- You are receiving this mail because: You are on the CC list for the issue.
