On 29/1/06 2:01, René Pfeiffer <[EMAIL PROTECTED]> wrote: > On Jan 23, 2006 at 1400 +0100, René Pfeiffer appeared and said: >> On Jan 21, 2006 at 1818 +0000, Chris Ridd appeared and said: >>> [...] >>> Actually, the version of LDAP.pm itself would be good, and the exact perl >>> version. >> >> The version of LDAP.pm is 0.32. I have attached the output of 'perl -V' >> to this mail. >> [...] > > I did some more testing, because I thought this error to be peculiar to > the server's AMD64 architecture. I get the same LDAP_DECODING_ERROR on > x86 and with OpenLDAP 2.2.x in addition to 2.3.x. I also tried the Perl > 5.8.7 version from Debian's testing tree along with Perl module updates. > I also get this error when skipping filter preparation with > Net::LDAP::Filter and simply use "(uid=*)" as search filter. In every > case the results from the OpenLDAP server are correct. I doublechecked > this by using tethereal and looking into the result packets. server_error() > says: > > decode error at /usr/share/perl5/Convert/ASN1/_decode.pm line 60 > > I even tried using different encodings though the whole scripts run with > UTF-8 enabled everywhere. I have attached a simple test script that was > taken from the CGIs that hit the error in the first place. > > I have really no idea what to test next or what to code differently, so > if you want me to run any other code please feel free to send > suggestions.
Can you send us the actual raw bytes that Convert::ASN1's trying to decode? Perhaps it *is* a 64-bit problem, though it is also possible that the servers involved are sending something back that we're not expecting. (I don't think it handles the ASN.1 extensibility required by RFC 2251, for instance, so non-standard (but "legally non-standard") things in the LDAP messages could cause a problem like this.) Just call $ldap->debug(3) prior to your search, and this will log the search op and the search results to stderr in hex. Cheers, Chris
