Just quick: The problem was a X509 Certificate parsing module who also use Convert::ASN1 for parsing the certificates. Instead of passing binary data to Convert::ASN1, my module passes the HEX encoded data. This was wrong and I fixed my own fault with converting the hex data to binary before passing to Convert::ASN1.
Sorry for the misunderstanding on my side.
Many thanks for your support!
Regards Roman
Graham Barr wrote:
On 29 Oct 2004, at 14:54, Roman Baumer wrote:
If up-to-date modules don't work, then try calling:
$ldap->debug(3);
just before you call the code that causes the decode failure. It should
print out a hex dump of the received message, which you should send to the
list for analysis.
Sure, here is the output:
Net::LDAP=HASH(0xd89ab8) received:
30 0C 02 01 3E 65 07 0A 01 00 04 00 04 00 __ __ 0...>e........
Net::LDAP=HASH(0xd89ab8) sending:
30 05 02 01 3F 42 00 __ __ __ __ __ __ __ __ __ 0...?B.
[Fri Oct 29 15:42:50 2004] [error] decode error 7b<=>30 at /usr/local/home/dsamgr/mdstools/lib/site_perl/5.6.1/Convert/ASN1/ _decode.pm line 110, <DATA> line 283
Hm, it is odd that it should report a sending packet just before the failure
This only happens when I try to fetch a userCertificate. And this is a little bit special, because in out LDAP server schema the attribute userCertificate is defined as string, rather then binary. (Hack to support an old version of Entrust ;-( )
Bye the way, although this attribute setup is unusual, I have no problems with other clients. It then looks like: "{ASN}308206C7..."
That should make no difference to this part of the code.
Let me know if you need the whole debug output.
The more the better. Although if it is big sending to the list might not be desirable :)
Send it to me, and Chris if he wants it
Graham.
