On Mon, May 21, 2007 at 12:34:35PM +0200, Sjoerd Simons wrote: > ldap_connect_to_host: Trying 2001:610:1118:0:204:75ff:fe95:b60 389 > ldap_connect_timeout: fd: 4 tm: 30 async: 0 > ldap_ndelay_on: 4 > ldap_is_sock_ready: 4 > ldap_ndelay_off: 4 > ldap_int_sasl_open: host=challenger.ipv6.spacelabs.nl > tls_write: want=73, written=73 > 0000: 16 03 01 00 44 01 00 00 40 03 01 46 51 6f ed 4f [EMAIL PROTECTED] > > 0010: 9c 6d 09 09 8e a8 5f 00 b6 a8 e2 26 c4 80 18 18 .m...?_.¶?â&Ä... > 0020: 80 a3 8e 24 0e 39 27 9b 6d 78 ad 00 00 18 00 33 .£.$.9'.mx....3 > 0030: 00 16 00 39 00 2f 00 0a 00 35 00 05 00 04 00 32 ...9./...5.....2 > 0040: 00 13 00 38 00 66 02 01 00 ...8.f... > tls_read: want=5, got=0 > > TLS: can't connect. > ldap_err2string > ldap_err2string
Finally found it! (Sorry for the late reply btw).. The problem isn't SSL, it's connecting to the wrong port! Instead of to the ldaps port (636), it's connecting to the plain ldap port (389).. I actually discovered this by looking at the diffs between the two versions. The offeding changes is: - p = strchr (p, ':'); + p = strchr (++p, ':'); Which actually fixes the bug that it thought an ldap uri always had a port specified. But now it detect that a uri doesn't have and as the non-ldaps port is default, it assumes that the user specified a non-default port (which isn't the case).. It adds a port to the uri given to libldap in the code just below... Woops Sjoerd -- That that is is that that is not is not.
