On 19 Jan 2012, at 01:35, John Devitofranceschi wrote:
> I am trying to use a slightly modified version of the Net::LDAP example
> scripts with paging and callbacks against Oracle Internet directory.
>
> I am using perl 5.14.2 and very fresh versions of all the CPAN modules.
>
> The script fails with:
>
> LDAP Search Failed: decode error 22 75 at
> /run/pd/csm/64-bit/cpan/5.14.2-2011.11/lib/Convert/ASN1/_decode.pm line
> 233, <DATA> line 522.
>
> And yet, a paged openldap ldapsearch works just fine (with "-E
> !pr=10/noprompt").
>
> If I strip out the paging code, the script works, but I really need to
> be able to use that extension.
>
> Here's the code:
> ...
> my $page = Net::LDAP::Control::Paged->new( size => 2 ); # keeping the size
> small for illus. purposes
> my @args = ( base => $base,
> scope => 'sub',
> filter => $query,
> attrs => \@attrs,
> callback => \&callback,
> control => [ $page ] );
>
>
> my $cookie;
> my $i = 1;
> while(1) {
> $ldap->debug(2);
> my $search = $ldap->search(@args);
>
> $search->code and do {
> exit print "LDAP Search Failed: " . $search->error . "\n";
> }
> ...
>
> }
> ...
>
>
> Running the script yields:
>
> Net::LDAP=HASH(0x10085c170) sending:
> Net::LDAP=HASH(0x10085c170) received:
>
> *an entry dump in hex*
>
> dn: *dn of an entry*
> Net::LDAP=HASH(0x10085c170) received:
>
> *anonther entry dump in hex*
>
> dn: *dn of another entry*
> Net::LDAP=HASH(0x10085c170) received:
>
> 30 84 00 00 00 45 02 01 01 65 84 00 00 00 3C 0A 0....E...e....<.
> 01 00 04 00 04 00 A0 84 00 00 00 2F 30 84 00 00 .........../0...
> 00 29 04 16 31 2E 32 2E 38 34 30 2E 31 31 33 35 .)..1.2.840.1135
> 35 36 2E 31 2E 34 2E 33 31 39 01 01 00 04 0C 30 56.1.4.319.....0
> 0A 02 01 00 04 05 35 31 61 32 66 __ __ __ __ __ ......51a2f
>
> LDAP Search Failed: decode error 22 75 at
> /run/pd/csm/64-bit/cpan/5.14.2-2011.11/lib/Convert/ASN1/_decode.pm line 233,
> <DATA> line 522.
>
>
> Is there a known issue with Oracle Internet Directory?
Not as far as I know, but perhaps no-one has tried this combination out much.
You've elided some code - I take it the elided code sets the page cookie as per
the man page example?
A decode of the last received packet looks like this:
0 69: SEQUENCE {
6 1: INTEGER 1
9 60: [APPLICATION 5] {
15 1: ENUMERATED 0
18 0: OCTET STRING
20 0: OCTET STRING
22 47: [0] {
28 41: SEQUENCE {
34 22: OCTET STRING '1.2.840.113556.1.4.319'
58 1: BOOLEAN FALSE
61 12: OCTET STRING 30 0A 02 01 00 04 05 35 31 61 32 66
: }
: }
: }
: }
(Output from dumpasn1 -z -e.)
In other words, it is an LDAPMessage with messageID 1 and a SearchResultDone
([APPLICATION 5] { ... }) and a sequence of Controls ([0] { ... }).
However, the nesting is wrong - the Controls (starting at byte 22) are being
encoded inside the SearchResultDone. That's not correct - they should be in the
outer LDAPMessage instead. Something like this:
: SEQUENCE {
: INTEGER 1
: [APPLICATION 5] {
: ENUMERATED 0
: OCTET STRING
: OCTET STRING
: }
: [0] {
: SEQUENCE {
: OCTET STRING '1.2.840.113556.1.4.319'
: BOOLEAN FALSE
: OCTET STRING 30 0A 02 01 00 04 05 35 31 61 32 66
: }
: }
: }
I think Oracle's sending bad protocol back.
However I don't /think/ we should be barfing like that, as LDAP has built-in
extensibility rules which state that clients/servers should try to ignore bits
of unexpected data as long as they're in the "right place". IIRC you can put in
custom stuff but only at the ends of certain structures and we should just
ignore it. But even if we ignored it, we still wouldn't find Oracle's misplaced
paged results control :-(
Two bugs for the price of one!
Chris
