I've read part of the source code of liblber and the problem seems related to
an invalid socket buffer (please don't take it for granted).
int ber_sockbuf_ctrl( Sockbuf *sb, int opt, void *arg )
{
Sockbuf_IO_Desc *p;
int ret = 0;
assert( sb != NULL );
assert( SOCKBUF_VALID( sb ) ); <<< this is the problem
----
I've also used a sniffer to spy the LDAP connection and check the difference
between success and failure.
The conversation is exactly the same byte by byte !
At some point the client should start another request but the connection is
suddently terminated by an RST packet from the client.
(logic if we consider that the client does not exit cleanly)
It should be interesting to notice that this failure point is not always
located the same offset but always immediately after getting a correct and
complete answer from the ldap server. I suppose this answer is complete and
correct because it is exectly the same than in the success case.
As a conclusion, if the same network dialog does not always produce the same
result, this problem may be the consequences of a deeper problem such as a
buffer overflow or a side effect of a function.
----
I've read somewhere that somone running some redhat distro (yes, i'm very
precise) has solved a similar problem by removing his rpm package and
installing a newer version of nss_ldap from openldap.org
I've checked openldap's changelog an found that they fixed some memory leak
bugs but nothing directly related with this problem. Anyway it should be a
good idea to make an (unofficial) openldap2.1.35 debian package for etch as
it may solve this problem.
If it solves the problem, it should be put in th etch repository very quickly.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
