[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: referral mess in HEAD
Now that the client hangs appear to be sorted out, there's something else
flaky going on. Using the same test tree as before, if I try to bind to the
server using a subordinate DN, the bind is referred incorrectly.
ldapsearch -x -C -b o=airbus -D cn=joe,ou=hamburg,o=eg,o=airbus -w secret -H
ldap://:20389 -d 7
The server's response to the bind is:
ber_get_next
ldap_read: want=9, got=9
0000: 30 41 02 01 01 61 3c 0a 01 0A...a<..
ldap_read: want=58, got=58
0000: 0a 04 0d 6f 3d 65 67 2c 6f 3d 61 69 72 62 75 73 ...o=eg,o=airbus
0010: 04 00 a3 26 04 24 6c 64 61 70 3a 2f 2f 31 32 37 ...&.$ldap://127
0020: 2e 30 2e 30 2e 31 3a 31 30 33 38 39 2f 6f 3d 65 .0.0.1:10389/o=e
0030: 67 2c 6f 3d 61 69 72 62 75 73 g,o=airbus
ber_get_next: tag 0x30 len 65 contents:
ldap_read: message type bind msgid 1, original id 1
ber_scanf fmt ({iaa) ber:
ber_scanf fmt ({v}) ber:
ldap_chase_v3referrals
ldap_url_parse_ext(ldap://127.0.0.1:10389/o=eg,o=airbus)
re_encode_request: new msgid 2, new dn <o=eg,o=airbus>
ber_scanf fmt ({it) ber:
ber_scanf fmt ({ia) ber:
re_encode_request new request is:
ldap_chase_v3referral: msgid 1, url "ldap://127.0.0.1:10389/o=eg,o=airbus"
....
and eventually the bind request is re-sent as
ber_flush: 33 bytes to sd 4
0000: 30 1f 02 01 02 60 1a 02 01 03 04 0d 6f 3d 65 67 0....`......o=eg
0010: 2c 6f 3d 61 69 72 62 75 73 80 06 73 65 63 72 65 ,o=airbus..secre
0020: 74 t
ldap_write: want=33, written=33
0000: 30 1f 02 01 02 60 1a 02 01 03 04 0d 6f 3d 65 67 0....`......o=eg
0010: 2c 6f 3d 61 69 72 62 75 73 80 06 73 65 63 72 65 ,o=airbus..secre
0020: 74 t
read1msg: referral chased, mark request completed, id = 1
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support