Re: error=Resource temporarily unavailable and Checkpoint Account Man agment Client

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

First, the "unavailable" errors is just non-blocking reads in action.


At 02:51 PM 9/21/00 +0200, Büttner, Björn, MTC-DIA wrote:
[trimmed and striped of your comments]
>[java client]
>ber_get_next: tag 0x30 len 51 contents:
>ber_dump: buf 0x81108c8, ptr 0x81108c8, end 0x81108fb
>        02 01 1a  J  .  c  n  =  s  d  f  d  s  f  s  ,
>        20  o  u  =  f  i  r  e  w  a  l  l  u  s  e  r
>         , 20  o  =  m  a  n  n  e  s  m  a  n  n  ,  c
>         =  d  e
>do_delete

This looks fine

>##################################################
>[checkpoint client]
>ber_get_next: tag 0x30 len 50 contents:
>ber_dump: buf 0x810c2a8, ptr 0x810c2a8, end 0x810c2da
>        02 02 00 0c  j  ,  c  n  =  s  d  f  d  s  f  s
>         ,  o  u  =  f  i  r  e  w  a  l  l  u  s  e  r
>         ,  o  =  m  a  n  n  e  s  m  a  n  n  ,  c  =
>         d  e
>unknown LDAP request 0x6a

This is an invalid LDAP PDU.  First, the length is not properly
encoded.  Second, it's using the "constructed" instead of a
"primitive" tag.

This behavior use of LDAP circa U-Mich 3.0, fixed in U-Mich 3.3.
OpenLDAP 1.2, like U-Mich 3.3, provided backwards compatibility
for such clients.  However, in OpenLDAP 2.0, we dropped support
for the bogus encoding as most applications had long since been
corrected.  Obviously, Checkpoint hasn't updated this client.

I suggest you pester them...


>send_ldap_disconnect 2:unknown LDAP request

OpenLDAP 2.0  handles unknown LDAP requests per RFC 2251.
We disconnect.

>slapd: result.c:88: req2res: Assertion `0' failed.
>Aborted

But we shouldn't abort.  I'll fix that.