RE: tls-related ldap_perror misleading in clients

["Howard Chu" <hyc@highlandsun.com>]

Aside from how the messages are printed, I think that ldap_start_tls_s
and/or ldap_int_tls_start ought to set ld->ld_errno before returning an
error. I think
that's the more immediate fix.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
> Sent: Sunday, September 02, 2001 1:36 AM

> At 01:26 AM 2001-09-02, Kurt D. Zeilenga wrote:
> >At 12:48 AM 2001-09-02, Pierangelo Masarati wrote:
> >>Hi.
> >>
> >>I got a nasty behavior out of the clients when using -ZZ, because I was
> >>having failure of the tls with reason ": Success". This is because the
> >>failure occurred in ldap_int_tls_start() which didn't properly set the
> >>error in the LDAP structure. So ldap_start_tls_s returns an error code,
> >>but when the ldap_perror is invoked by the ldap*.c client the string is
> >>success. I fixed it by using ldap_err2string() instead of ldap_perror
> >>(which is deprecated in the code according to a comment);
> >>if there's consensus I'll patch all the clients.
> >
> >For now, this is likely the best solution.
>
> Actually, use of just ldap_err2string() will not print the
> server provided additional information.  So, I suggest using
> ldap_get_option() to get the resultCode and error message.  If
> resultCode is not success, then one can mimic ldap_perror()
> (w/ error message).  If resultCode is success, then then a
> similar error message should be printed using the
> ldap_err2string().
>