Ralf Haferkamp wrote:
Hi,
On Thursday 14 October 2010 02:02:17 Howard Chu wrote:
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap
Modified Files: sasl.c 1.82 -> 1.83
Log Message: More for prev commit. What about ldap_pvt_sasl_getmechs() ?
CVS Web URLs: http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/
http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/sasl .cChanges are generally available on cvs.openldap.org (and CVSweb) within 30 minutes of being committed.
Please review and comment, thanks.
It seems that SASL/GSSAPI binds broke somehow. At least for me ldapsearch from current HEAD hangs in ldap_int_select(). I have 2.4.23 on the server side. Here is the end of ldapsearch's debug output:
Thanks, I suspected that might happen. I only tested DIGEST-MD5 and EXTERNAL so far. Will look into it shortly.
Looking at it again, it strikes me that perhaps this restructuring was an exercise in futility. The ldap_host_connected_to() function can block doing a DNS lookup, and also the GSSAPI mechanism can block while obtaining a service ticket. (In addition to any blocking during ldap_pvt_sasl_getmechs()...) As such, it would need a lot more work to make it fully asynchronous. We could create the infrastructure needed to make ldap_host_connected_to() and ldap_pvt_sasl_getmechs() fully asynch, but we have no such control over the SASL mechanisms.
-----------------8<----------------------------------- res_errno: 14, res_error:<SASL(0): successful result:>, res_matched:<> ldap_free_request (origid 3, msgid 3) ldap_int_sasl_bind:<null> ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x624ee0 ptr=0x624ee3 end=0x624f2a len=71 0000: 61 45 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 29 aE.......SASL(0) 0010: 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 73 : successful res 0020: 75 6c 74 3a 20 87 20 05 04 05 ff 00 0c 00 00 00 ult: . ......... 0030: 00 00 00 05 5c ee 23 07 01 00 00 c3 56 03 6d 56 .....#.....V.mV 0040: 24 c6 ab e5 96 61 1c $....a. ber_scanf fmt (O) ber: ber_dump: buf=0x624ee0 ptr=0x624f08 end=0x624f2a len=34 0000: 87 20 05 04 05 ff 00 0c 00 00 00 00 00 00 05 5c . .............\ 0010: ee 23 07 01 00 00 c3 56 03 6d 56 24 c6 ab e5 96 .#.....V.mV$.... 0020: 61 1c a. ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x624ee0 ptr=0x624ee3 end=0x624f2a len=71 0000: 61 45 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 29 aE.......SASL(0) 0010: 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 73 : successful res 0020: 75 6c 74 3a 20 87 20 05 04 05 ff 00 0c 00 00 00 ult: . ......... 0030: 00 00 00 05 5c ee 23 07 01 00 00 c3 56 03 6d 56 .....#.....V.mV 0040: 24 c6 ab e5 96 61 1c $....a. ber_scanf fmt (x) ber: ber_dump: buf=0x624ee0 ptr=0x624f08 end=0x624f2a len=34 0000: 87 20 05 04 05 ff 00 0c 00 00 00 00 00 00 05 5c . .............\ 0010: ee 23 07 01 00 00 c3 56 03 6d 56 24 c6 ab e5 96 .#.....V.mV$.... 0020: 61 1c a. ber_scanf fmt (}) ber: ber_dump: buf=0x624ee0 ptr=0x624f2a end=0x624f2a len=0
sasl_client_step: 0 SASL username: ldap/bronsted.g17.lan@G17.LAN SASL SSF: 56 ldap_pvt_sasl_generic_install SASL data security layer installed. ldap_msgfree ldap_result ld 0x6166c0 msgid 3 wait4msg ld 0x6166c0 msgid 3 (infinite timeout) wait4msg continue ld 0x6166c0 msgid 3 all 1 ** ld 0x6166c0 Connections:
- host: nibbler.g17.lan port: 389 (default) refcnt: 1 status: Connected last used: Fri Oct 15 11:51:43 2010
** ld 0x6166c0 Outstanding Requests: Empty ld 0x6166c0 request count 0 (abandoned 0) ** ld 0x6166c0 Response Queue: Empty ld 0x6166c0 response count 0 ldap_chkResponseList ld 0x6166c0 msgid 3 all 1 ldap_chkResponseList returns ld 0x6166c0 NULL ldap_int_select -----------------8<-----------------------------------