[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Start TLS extended request
Hi,
Thanks for your reply. I have done some more investigation into this and
have the questions.
This is with regard to ldap_start_tls_s extended operation. Please read
through with patience (its a bit long with all kinds of debug dumps). I am
using openldap 2.1.22 release.
I am thankful for any feedback.
the debug and dump traces follow below.
Question 1) "send_ldap_extended: err=0 oid= len=0"
what i am trying to understand is why isnt the responseName field set?
2380 says requestName=OID and requestValue field absent in the request and
responseName=requestName=OID and responseValue field absent in the
response.
the ber dumps and the ber debug output above also say this.
The result code seems to be correctly set, but why isnt the responseName
being set to OID (or did i understand the implementation incorrectly?)
Question 2)
I was trying to allow the slapd to ignore the extra requestData at the end
of the PDU (just curious to see what the winclient says - i understand its
against the protocol)
so now slapd was sending the same response values to both openldap client
and winldap client. but winldap client errors by saying "operations
error". i've attached the responses below
slapd response: same as for openldap client
send_ldap_extended: err=0 oid= len=0
send_ldap_response: msgid=1 tag=120 err=0
ber_flush: 14 bytes to sd 9
0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........
ldap_write: want=14, written=14
0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........
winldap client:
prot ver=3
tls failed 1 - Operations Error
slapd exit:
TLS trace: SSL_accept:before/accept initialization
tls_read: want=11 error=Connection reset by peer
TLS trace: SSL_accept:error in SSLv2/v3 read client hello A
TLS: can't accept.
connection_read(9): TLS accept error error=-1 id=0, closing
I am wondering and curious as to why winldap rejected the response? (i
think it is because the oid was null)
starttls.c wasnt setting the rspoid argument, so i changed it to set it
the oid value "1.3.6.1.4.1.1466.20037", now everything seems to work fine
(in opendlap and winldap client worlds),
NEW slapd response with OID output:
--> send_ldap_extended: err=0 oid=1.3.6.1.4.1.1466.20037 len=0
send_ldap_response: msgid=1 tag=120 err=0
ber_flush: 38 bytes to sd 9
0000: 30 24 02 01 01 78 1f 0a 01 00 04 00 04 00 8a 16 0$...x..........
0010: 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 36 1.3.6.1.4.1.1466
0020: 2e 32 30 30 33 37 .20037
Question 3)
The winldap client still sends some "extra data namely - 00 00" which I
have no clue what it is..? (do you know what that piece means?)
Question 4)
is this correct (and does the latest version send the oid back?)
Question 5)
> (winldap) you used, is malformed. Specifically, the
> PDU contains request data when shouldn't. You should
do those values mean that the request data tag is present but has null
values? if yes, is that still invalid ? (coz the field is null which is
tha same as being absent rite?)
the debug and dump traces follow below.
Thanks,
Siva
/**** debug and dumps ****/
The ber dumps indicate the following:
OpenLDAP request:
30 ld {,len=29
02 01 01 int,len=1,value=1
77 18 ext_req,reqlen=24
80 16 (utf8?),slen=22
31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 oid=1.3.6.1.4.1.1466.20037
winldap request:
30 84 00 00 00 23 {, len=4, value=35
02 01 01 int,len=1,value=1
77 84 00 00 00 1a ext_req, int, len=4, value=reqlen=26
80 16 (utf8?), slen=22
31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 oid=1.3.6.1.4.1.1466.20037
81 00 (request value?),null?
00 00 ?/**???**/
slapd response for openldap client:
30 0c {,len=12
02 01 01 int,len=1,value=1
78 07 ext_res, reslen=7
0a 01 00 enum, len=1,value=0 (error=0 no error)
04 00 str,""
04 00 str,""
slapd response for winldap client:
30 24 {,len=36
02 01 01 int,len=1,value=1
78 1f ext_res, reslen=31
0a 01 02 enum, len=1,value=0 (error=2, protocol error)
04 00 str,""
04 18 6e 6f 20 72 65 71 75 65 73 74 20 64 61 74 61 20 65 78 70 65 63 74 65 64 str,slen=24,no request data expected
detailed dumps:
/*** openldap client request ***/
ldap_open_defconn: successful
ldap_send_server_request
ber_flush: 31 bytes to sd 3
0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1
0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037
ldap_write: want=31, written=31
0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1
0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037
ldap_result msgid 1
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
wait4msg (infinite timeout), msgid 1
wait4msg continue, msgid 1, all 1
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
do_ldap_select
read1msg: msgid 1, all 1
ber_get_next
ldap_read: want=1, got=1
0000: 30 0
ldap_read: want=1, got=1
0000: 0c .
ldap_read: want=12, got=12
0000: 02 01 01 78 07 0a 01 00 04 00 04 00 ...x........
ber_get_next: tag 0x30 len 12 contents:
ber_dump: buf=0x0804c620 ptr=0x0804c620 end=0x0804c62c len=12
0000: 02 01 01 78 07 0a 01 00 04 00 04 00 ...x........
ldap_read: message type extended-result msgid 1, original id 1
ber_scanf fmt ({iaa) ber:
ber_dump: buf=0x0804c620 ptr=0x0804c623 end=0x0804c62c len=9
0000: 78 07 0a 01 00 04 00 04 00 x........
ber_scanf fmt ({iaa}) ber:
ber_dump: buf=0x0804c620 ptr=0x0804c623 end=0x0804c62c len=9
0000: 78 07 0a 01 00 04 00 04 00 x........
new result: res_errno: 0, res_error: <>, res_matched: <>
read1msg: 0 new referrals
read1msg: mark request completed, id = 1
request 1 done
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_free_connection
ldap_free_connection: refcnt 1
ldap_parse_extended_result
ber_scanf fmt ({iaa) ber:
ber_dump: buf=0x0804c620 ptr=0x0804c623 end=0x0804c62c len=9
0000: 78 07 0a 01 00 04 00 04 00 x........
ldap_parse_result
ber_scanf fmt ({iaa) ber:
ber_dump: buf=0x0804c620 ptr=0x0804c623 end=0x0804c62c len=9
0000: 78 07 0a 01 00 04 00 04 00 x........
ber_scanf fmt (}) ber:
ber_dump: buf=0x0804c620 ptr=0x0804c62c end=0x0804c62c len=0
ldap_msgfree
TLS trace: SSL_connect:before/connect initialization
/*** slapd response for openldap client's request ***/
ber_get_next
ldap_read: want=8, got=8
0000: 30 1d 02 01 01 77 18 80 0....w..
ldap_read: want=23, got=23
0000: 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e 31 34 36 .1.3.6.1.4.1.146
0010: 36 2e 32 30 30 33 37 6.20037
ber_get_next: tag 0x30 len 29 contents:
ber_dump: buf=0x0a088f20 ptr=0x0a088f20 end=0x0a088f3d len=29
0000: 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 ...w...1.3.6.1.4
0010: 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .1.1466.20037
do_extended
ber_scanf fmt ({m) ber:
ber_dump: buf=0x0a088f20 ptr=0x0a088f23 end=0x0a088f3d len=26
0000: 77 18 80 16 31 2e 33 2e 36 2e 31 2e 34 2e 31 2e w...1.3.6.1.4.1.
0010: 31 34 36 36 2e 32 30 30 33 37 1466.20037
do_extended: oid=1.3.6.1.4.1.1466.20037
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable
ber_get_next on fd 9 failed errno=11 (Resource temporarily unavailable)
send_ldap_extended: err=0 oid= len=0
send_ldap_response: msgid=1 tag=120 err=0
ber_flush: 14 bytes to sd 9
0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........
ldap_write: want=14, written=14
0000: 30 0c 02 01 01 78 07 0a 01 00 04 00 04 00 0....x........
daemon: select: listen=5 active_threads=0 tvp=NULL
daemon: activity on 1 descriptors
daemon: activity on: 9r
daemon: read activity on 9
connection_get(9)
connection_get(9): got connid=1
connection_read(9): checking for input on id=1
TLS trace: SSL_accept:before/accept initialization
tls_read: want=11, got=11
/*** slapd response for a win-client's (using winldap) request ***/
ldap_read: want=8, got=8
0000: 30 84 00 00 00 23 02 01 0....#..
ldap_read: want=33, got=33
0000: 01 77 84 00 00 00 1a 80 16 31 2e 33 2e 36 2e 31 .w.......1.3.6.1
0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 81 .4.1.1466.20037.
0020: 00 .
ber_get_next: tag 0x30 len 35 contents:
ber_dump: buf=0x0a088d60 ptr=0x0a088d60 end=0x0a088d83 len=35
0000: 02 01 01 77 84 00 00 00 1a 80 16 31 2e 33 2e 36 ...w.......1.3.6
0010: 2e 31 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 .1.4.1.1466.2003
0020: 37 81 00 7..
ber_get_next
ldap_read: want=8 error=Resource temporarily unavailable
do_extended
ber_scanf fmt ({m) ber:
ber_dump: buf=0x0a088d60 ptr=0x0a088d63 end=0x0a088d83 len=32
0000: 77 84 00 00 00 1a 80 16 31 2e 33 2e 36 2e 31 2e w.......1.3.6.1.
0010: 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 81 00 4.1.1466.20037..
ber_scanf fmt (m) ber:
ber_dump: buf=0x0a088d60 ptr=0x0a088d81 end=0x0a088d83 len=2
0000: 00 00 ..
do_extended: oid=1.3.6.1.4.1.1466.20037
send_ldap_extended: err=2 oid= len=0
ber_get_next on fd 9 failed errno=11 (Resource temporarily unavailable)
send_ldap_response: msgid=1 tag=120 err=2
ber_flush: 38 bytes to sd 9
0000: 30 24 02 01 01 78 1f 0a 01 02 04 00 04 18 6e 6f 0$...x........no
0010: 20 72 65 71 75 65 73 74 20 64 61 74 61 20 65 78 request data ex
0020: 70 65 63 74 65 64 pected
ldap_write: want=38, written=38
0000: 30 24 02 01 01 78 1f 0a 01 02 04 00 04 18 6e 6f 0$...x........no
0010: 20 72 65 71 75 65 73 74 20 64 61 74 61 20 65 78 request data ex
0020: 70 65 63 74 65 64 pected
/*** end of debug and dumps ****/
thanks,
Siva
On Thu, 22 Jan 2004, Kurt D. Zeilenga wrote:
> At 09:16 AM 1/22/2004, Siva Kollipara wrote:
> >any suggestion on how to resolve and get this working ?
>
> The PDU from the client, as produced by the library
> (winldap) you used, is malformed. Specifically, the
> PDU contains request data when shouldn't. You should
> report a bug to the maintainer of that library.
>
> Kurt
>
v