Full_Name: Vernon Smith Version: 2.4.47 OS: Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2601:40d:4300:679a:8d9a:95ec:46f9:30fd) I looked at the release notes and there have been a few issues with Async mode with TSL in 2.4. I had been using 2.3.20 with my own patches to make Async mode with TLS work with my aplication. I need to upgrade to 2.4 but I have tried many version of it and none have worked. The basic issue is that the TLS code is never called so LDAPS connections fail. My symptoms are very similar to the bug report that caused a fix in 2.4.26 but 2.4.26 is not working for me. I see the same issue with 2.4.47. If I don't use LDAP_OPT_CONNECT_ASYNC then the connection works and I get this trace: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP test.interlinknetworks.com:636 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 192.168.3.26:636 ldap_pvt_connect: fd: 10 tm: 3 async: 0 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_int_poll: fd: 10 tm: 3 ldap_is_sock_ready: 10 ldap_ndelay_off: 10 ldap_pvt_connect: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:unknown state TLS certificate verification: depth: 1, err: 0, subject: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest@interlinknetworks.com, issuer: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest@interlinknetworks.com TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=Michigan/L=Ann Arbor/O=Interlink Networks Services, LLC./OU=Quality Assurance/CN=test.interlinknetworks.com/emailAddress=QAtest@interlinknetworks.com, issuer: /C=AA/ST=Michigan/L=Ann Arbor/O=Interlink Networks, Inc./OU=Quality Assurance/CN=autoTest CA/emailAddress=QAtest@interlinknetworks.com TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state TLS trace: SSL_connect:unknown state ldap_open_defconn: successful ldap_send_server_request But with LDAP_OPT_CONNECT_ASYNC enabled I never see the TLS code called and the connection fails. The trace is: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP test.interlinknetworks.com:636 ldap_new_socket: 10 ldap_prepare_socket: 10 ldap_connect_to_host: Trying 192.168.3.26:636 ldap_pvt_connect: fd: 10 tm: 3 async: -1 ldap_ndelay_on: 10 attempting to connect: connect errno: 115 ldap_open_defconn: successful ldap_send_server_request ... ldap_result ld 0x9bd6f70 msgid 1 wait4msg ld 0x9bd6f70 msgid 1 (timeout 0 usec) wait4msg continue ld 0x9bd6f70 msgid 1 all 1 ** ld 0x9bd6f70 Connections: * host: test.interlinknetworks.com port: 636 (default) refcnt: 2 status: Connected last used: Mon Jan 14 15:33:57 2019 ** ld 0x9bd6f70 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x9bd6f70 request count 1 (abandoned 0) ** ld 0x9bd6f70 Response Queue: Empty ld 0x9bd6f70 response count 0 ldap_chkResponseList ld 0x9bd6f70 msgid 1 all 1 ldap_chkResponseList returns ld 0x9bd6f70 NULL ldap_int_select read1msg: ld 0x9bd6f70 msgid 1 all 1 ber_get_next failed. ldap_err2string ... Can't contact LDAP server Thanks, Vern
<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p><font face="Calibri">I reviewed some of the initial discussion about this same issue which lead to this fix in version 2.4.26, "</font>Fixed libldap ASYNC TLS setup (ITS#6828)", and looked at the code that Ian Puleston suggested should be fixed in ldap_int_open_connection. This routine does have the code to do what was need for TSL to work but was not called since it received an error code of -2 not 0. The -2 simply indicated that this was an asynchronous call. I changed the test to call the TSL setup if the return code was either 0 or -2. This fixes my issue. Here is my patch.</p> <p>--- openldap-2.4.47/libraries/libldap/open.c 2018-12-19 10:57:06.000000000 -0500<br> +++ openldap-2.4.47.mod/libraries/libldap/open.c 2019-01-26 18:24:48.000000000 -0500<br> @@ -440,7 +440,7 @@<br> #endif<br> <br> #ifdef HAVE_TLS<br> - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD ||<br> + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD ||<br> strcmp( srv->lud_scheme, "ldaps" ) == 0 ))<br> {<br> ++conn->lconn_refcnt; /* avoid premature free */<br> </p> <p><font face="Arial,Verdana,Helvetica">Thanks,<br> Vern</font><br> <font face="Arial,Verdana,Helvetica"></font></p> </body> </html>
Hi, Please read: <https://www.openldap.org/devel/contributing.html> and re-submit the patch accordingly. Please do not use HTML email. Thanks! --On Tuesday, January 29, 2019 6:05 AM +0000 vsmith@interlinknetworks.com wrote: > <html> > <head> > > <meta http-equiv="content-type" content="text/html; charset=UTF-8"> > </head> > <body text="#000000" bgcolor="#FFFFFF"> > <p><font face="Calibri">I reviewed some of the initial discussion > about this same issue which lead to this fix in version 2.4.26, > "</font>Fixed libldap ASYNC TLS setup (ITS#6828)", and looked at > the code that Ian Puleston suggested should be fixed in > ldap_int_open_connection. This routine does have the code to do > what was need for TSL to work but was not called since it received > an error code of -2 not 0. The -2 simply indicated that this was > an asynchronous call. I changed the test to call the TSL setup if > the return code was either 0 or -2. This fixes my issue. Here is > my patch.</p> > <p>--- openldap-2.4.47/libraries/libldap/open.c?????? 2018-12-19 > 10:57:06.000000000 -0500<br> > +++ openldap-2.4.47.mod/libraries/libldap/open.c?????? 2019-01-26 > 18:24:48.000000000 -0500<br> > @@ -440,7 +440,7 @@<br> > ??#endif<br> > ??<br> > ??#ifdef HAVE_TLS<br> > -?????? if (rc == 0 && ( ld->ld_options.ldo_tls_mode == > LDAP_OPT_X_TLS_HARD ||<br> > +?????? if ((rc == 0 || rc == -2) && ( > ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD ||<br> > ???????? ?????? strcmp( srv->lud_scheme, "ldaps" ) == 0 ))<br> > ???????? {<br> > ???????? ?????? ++conn->lconn_refcnt;?????? /* avoid premature > free */<br> </p> > <p><font face="Arial,Verdana,Helvetica">Thanks,<br> > Vern</font><br> > <font face="Arial,Verdana,Helvetica"></font></p> > </body> > </html> > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
I reviewed some of the initial discussion about this same issue which lead to this fix in version 2.4.26, "Fixed libldap ASYNC TLS setup (ITS#6828)", and looked at the code that Ian Puleston suggested should be fixed in ldap_int_open_connection. This routine does have the code to do what was need for TSL to work but was not called since it received an error code of -2 not 0. The -2 simply indicated that this was an asynchronous call. I changed the test to call the TSL setup if the return code was either 0 or -2. This fixes my issue. Here is my patch. --- openldap-2.4.47/libraries/libldap/open.c 2018-12-19 10:57:06.000000000 -0500 +++ openldap-2.4.47.mod/libraries/libldap/open.c 2019-01-26 18:24:48.000000000 -0500 @@ -440,7 +440,7 @@ #endif #ifdef HAVE_TLS - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) { ++conn->lconn_refcnt; /* avoid premature free */ Thanks, Vernon
--On Tuesday, January 29, 2019 4:51 PM +0000 vsmith@interlinknetworks.com wrote: > --- openldap-2.4.47/libraries/libldap/open.c?????? 2018-12-19 > 10:57:06.000000000 -0500 > +++ openldap-2.4.47.mod/libraries/libldap/open.c?????? 2019-01-26 > 18:24:48.000000000 -0500 > @@ -440,7 +440,7 @@ > ??#endif > > ??#ifdef HAVE_TLS > -?????? if (rc == 0 && ( ld->ld_options.ldo_tls_mode == > LDAP_OPT_X_TLS_HARD || +?????? if ((rc == 0 || rc == -2) && ( > ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > ???????? ?????? strcmp( srv->lud_scheme, "ldaps" ) == 0 )) > ???????? { > ???????? ?????? ++conn->lconn_refcnt;?????? /* avoid premature free */ This is not a valid patch. I don't know if it's your email client that is destroying the patch? I suggest uploading it to the FTP site and responding with the link to the file. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
I Tried to upload it to the openldap ftp server but was not successful so I am trying the patch again here. diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c index bb81d86..20b3dfc 100644 --- a/libraries/libldap/open.c +++ b/libraries/libldap/open.c @@ -489,7 +489,7 @@ ldap_int_open_connection( #endif #ifdef HAVE_TLS - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) { ++conn->lconn_refcnt; /* avoid premature free */ Thanks, Vern On Tue, January 29, 2019 12:29 pm, Quanah Gibson-Mount wrote: > --On Tuesday, January 29, 2019 4:51 PM +0000 vsmith@interlinknetworks.com > wrote: > > > > >> --- openldap-2.4.47/libraries/libldap/open.c?????? 2018-12-19 >> 10:57:06.000000000 -0500 >> +++ openldap-2.4.47.mod/libraries/libldap/open.c?????? 2019-01-26 >> 18:24:48.000000000 -0500 >> @@ -440,7 +440,7 @@ >> ??#endif >> >> >> ??#ifdef HAVE_TLS >> -?????? if (rc == 0 && ( ld->ld_options.ldo_tls_mode == >> LDAP_OPT_X_TLS_HARD || +?????? if ((rc == 0 || rc == -2) && ( >> ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || ???????? ?????? strcmp( >> srv->lud_scheme, "ldaps" ) == 0 )) ???????? { >> ???????? ?????? ++conn->lconn_refcnt;?????? /* avoid premature free */ >> > > This is not a valid patch. I don't know if it's your email client that is > destroying the patch? I suggest uploading it to the FTP site and responding with the > link to the file. > > Thanks, > Quanah > > > > -- > > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > >
--On Wednesday, January 30, 2019 1:44 AM -0500 Vernon Smith <vsmith@interlinknetworks.com> wrote: > I Tried to upload it to the openldap ftp server but was not successful so > I am trying the patch again here. > > diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c > index bb81d86..20b3dfc 100644 > --- a/libraries/libldap/open.c > +++ b/libraries/libldap/open.c > @@ -489,7 +489,7 @@ ldap_int_open_connection( > #endif > > #ifdef HAVE_TLS > - if (rc == 0 && ( ld->ld_options.ldo_tls_mode == LDAP_OPT_X_TLS_HARD || > + if ((rc == 0 || rc == -2) && ( ld->ld_options.ldo_tls_mode == > LDAP_OPT_X_TLS_HARD || strcmp( srv->lud_scheme, "ldaps" ) == 0 )) > { > ++conn->lconn_refcnt; /* avoid premature free */ That worked, thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
changed notes
--On Wednesday, January 30, 2019 3:15 PM +0000 quanah@symas.com wrote: > --On Wednesday, January 30, 2019 1:44 AM -0500 Vernon Smith > <vsmith@interlinknetworks.com> wrote: > >> I Tried to upload it to the openldap ftp server but was not successful so >> I am trying the patch again here. Thanks for the report, this has been committed to git master (and will be part of the next RE24 release). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
changed notes changed state Open to Test moved from Incoming to Software Bugs
changed notes changed state Test to Release
Fixed in master Fixed in RE24 (2.4.48)
changed notes changed state Release to Closed