Ralf Haferkamp wrote:
Hi,
On Thursday 14 October 2010 02:02:17 Howard Chu wrote:
h...@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
.c
Changes 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....@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<-----------------------------------
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
