[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Netscape client misparsing the bind response



I don't work on the Netscape Communicator client, but I do work on the
Netscape/Mozilla SDK that it uses).

Question: Does everything work fine if you do not use SSL/TLS?  It does
sound like one end or the other is getting our of synch with the data
stream, although that surprises me.  I suspect the encoding and decoding
code is correct on both ends, which makes me suspect something in the
SSL/TLS layers.

Can you produce a protocol trace (of the SSL session and the LDAP
stream)?

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?


Julio Sánchez Fernández wrote:
> 
> I am testing the TLS thing and, since I cannot bind with the client
> certificate, I am trying user (i.e. email address) and password
> over SSL.
> 
> Well, it fails mysteriously:
> 
> Aug  3 19:07:07 andromeda slapd[8243]: daemon: conn=0 fd=8 connection from IP=74.3.11.123:23336 (IP=0.0.0.0:1636) accepted.
> Aug  3 19:07:07 andromeda slapd[8244]: conn=0 op=0 BIND dn="" method=128
> Aug  3 19:07:07 andromeda slapd[8244]: conn=0 op=0 RESULT err=0 tag=97 text=(null)
> Aug  3 19:07:11 andromeda slapd[8245]: conn=0 op=1 UNBIND
> Aug  3 19:07:11 andromeda slapd[8245]: conn=-1 fd=8 closed.
> 
> Here, Netscape is trying an anonymous (v2, BTW) bind before searching
> email address and such.  The server thinks the bind succeeded, but
> Netscape thinks it is an error.  To be precise, it thinks that the
> error is 0x61 LDAP_REFERRAL_LIMIT_EXCEEDED (i.e. it is reading the tag
> as the error).  However, for that to happen, it would have to
> get out of sync with the stream.  The relevant part of the trace is:
> 
> ber_get_next: tag 0x30 len 12 contents:
> ber_dump: buf 0x81a31b8, ptr 0x81a31b8, end 0x81a31c4
>         02 01 01  ` 07 02 01 02 04 00 80 00
> ber_get_next
> ber_get_next on fd 8 failed errno 11 (Resource temporarily unavailable)
>         *** got 135934060 of 0 so far
> daemon: select: listen=4 active_threads=1 tvp=NULL
> daemon: select: listen=5 active_threads=1 tvp=NULL
> do_bind
> ber_scanf fmt ({iat) ber:
> ber_dump: buf 0x81a31b8, ptr 0x81a31bb, end 0x81a31c4
>          ` 07 02 01 02 04 00 80 00
> ber_scanf fmt (o}) ber:
> ber_dump: buf 0x81a31b8, ptr 0x81a31c2, end 0x81a31c4
>         80 00
> do_bind: version 2 dn () method 128
> send_ldap_result: conn=0 op=0 p=2
> send_ldap_result: 0::
> send_ldap_response: tag=97 msgid=1 err=0
> 
> Any ideas?
> 
> Julio