Re: [Fwd] inconsistency / bug / something in Net::LDAP.

[Kurt D. Z. <Ku...@Op...>]

At 07:19 AM 12/18/00 +0000, Graham Barr wrote:
>To: gb...@po...
>From: as...@uf...
>Subject: inconsistency / bug / something in Net::LDAP.
>Date: Sun, 17 Dec 2000 21:32:18 -0500
>
>I've been having some problems using Net::LDAP against an OpenLDAP server of
>moderately recent version (Sorry, I don't know precisely which version).

I suggest you determine exactly which version of OpenLDAP you
are using (updating if appropriate) and file an issue report
with OpenLDAP <http://www.openldap.org/its/> (providing relevant
details, of course).  If you have other data which confirms that
this problem is apparent with OpenLDAP provided tools, please
provide this.


>I have determined that the problem is due to an arguably "wrong" behavior by
>the server, which is nonetheless apparently within the LDAP spec;  To wit, on
>query after succesful bind, the first packet returned is the bind success.

I would not argue that the behavior you describe is within
specification.


>So it goes
>
>>>  Bind req
><<  Bind OK.
>>>  Search filter
><<  Bind OK.
>
>[ protocol error ] 
>
>I'll include the output from a debug => 15 session for an example below.
>
>I took a look at the network traffic for a similar session for the ldapsearch
>client that comes with OpenLDAP, and determined that their ldapsearch discards
>"Answers to messages we're not expecting answers for".

The C API supports asking for what is expected and holding that
which is not asked for until asked.  Some applications never
bother to ask for all that is returned.  Even for simple
applications, such as ldapsearch(1), this is dangerous as one
may not detect and report unsolicited notifications.

>>>  Bind req
><<  Bind OK.
>>>  Search filter
><<  Bind OK.
>[ that's useless, I'll ditch it. ] 
><<  Search results
>
>
>
>After some noodling around in your code, I came up with the following patch
>which imitates that behavior, asking for another answer if the answer received
>is to a different question than I asked.
>
>*** /space/CPAN/build/perl-ldap-0.22/blib/lib/Net/LDAP.pm       Thu Sep 14 14:53:39 2000
>--- ./LDAP.pm   Sun Dec 17 21:20:31 2000
>***************
>*** 618,623 ****
>--- 618,629 ----
>  
>      my $mid = $result->{messageID};
>  
>+     if ( $mid != $what ) 
>+       {
>+       print STDERR "this ($mid) is not the message ($what) you're looking for.\n" if $debug;
>+       next;
>+       }
>+ 
>      my $mesg = $ldap->{net_ldap_mesg}->{$mid} or
>        return LDAP_PROTOCOL_ERROR;
>
>
>
>....  I thought pretty long and hard before deciding to suggest that you make
>this addition, because I see your fatal exception to "You answered a different
>question than I asked" as one reasonable interpretation of the RFC.  However,
>I decided to submit the patch anyway, following the theory of being generous
>in what you accept, and rigid in what you emit.  I think the OpenLDAP server
>is not being a great neighbor by tossing whatever answer it has close to hand
>in this case, but I do not think they actually violate the spec; After all,
>it's reasonable for them to presume that "That's why we've got message IDs in
>all the communications; the client should be aware of it".  Rude, but
>reasonable.

I suspect this to be a bug in the server.  It should be reported
so that it can be properly investigated.

I would not suggest any changes to net::LDAP to work around this
bug.  It's much better to fix the server than to propagate changes
which might have undesirable side effects.

>So, I respectfully submit this patch as making Net::LDAP more flexible without
>damaging its' utility.
>
>Thanks for your consideration.
>
>
>- Allen S. Rout
>
>
>
>
>
>Failed session example (yes, I've since changed my password. :) -- 
>
>[asr@rah perl]$ ./getattrauth.pl 
>Net::LDAP=HASH(0x80e4a44) sending:
>
>30 3E 02 01 01 60 39 02 01 02 04 25 63 6E 3D 61 0>...`9....%cn=a
>73 72 2C 20 6F 3D 55 6E 69 76 65 72 73 69 74 79 sr, o=University
>20 6F 66 20 46 6C 6F 72 69 64 61 2C 20 63 3D 55  of Florida, c=U
>53 80 0D 50 6F 64 64 79 54 72 61 69 6E 69 6E 67 S..PoddyTraining
>
>0000 30   62: SEQUENCE {
>0002 02    1:   INTEGER = 1
>0005 60   57:   [APPLICATION 0] {
>0007 02    1:     INTEGER = 2
>000A 04   37:     STRING = 'cn=asr, o=University of Florida, c=US'
>0031 80   13:     [CONTEXT 0]
>0033        :       50 6F 64 64 79 54 72 61 69 6E 69 6E 67 __ __ __ PoddyTraining
>0040        :   }
>0040        : }
>Net::LDAP=HASH(0x80e4a44) received:
>
>30 0C 02 01 01 61 07 0A 01 00 04 00 04 00 __ __ 0....a........
>
>0000 30   12: SEQUENCE {
>0002 02    1:   INTEGER = 1
>0005 61    7:   [APPLICATION 1] {
>0007 0A    1:     ENUM = 0
>000A 04    0:     STRING = ''
>000C 04    0:     STRING = ''
>000E        :   }
>000E        : }
>Net::LDAP=HASH(0x80e4a44) sending:
>
>30 40 02 01 02 63 3B 04 1D 6F 3D 55 6E 69 76 65 0@...c;..o=Unive
>72 73 69 74 79 20 6F 66 20 46 6C 6F 72 69 64 61 rsity of Florida
>2C 20 63 3D 55 53 0A 01 02 0A 01 02 02 01 00 02 , c=US..........
>01 00 01 01 00 A3 09 04 02 63 6E 04 03 61 73 72 .........cn..asr
>30 00 __ __ __ __ __ __ __ __ __ __ __ __ __ __ 0.
>
>0000 30   64: SEQUENCE {
>0002 02    1:   INTEGER = 2
>0005 63   59:   [APPLICATION 3] {
>0007 04   29:     STRING = 'o=University of Florida, c=US'
>0026 0A    1:     ENUM = 2
>0029 0A    1:     ENUM = 2
>002C 02    1:     INTEGER = 0
>002F 02    1:     INTEGER = 0
>0032 01    1:     BOOLEAN = FALSE
>0035 A3    9:     [CONTEXT 3] {
>0037 04    2:       STRING = 'cn'
>003B 04    3:       STRING = 'asr'
>0040        :     }
>0040 30    0:     SEQUENCE {
>0042        :     }
>0042        :   }
>0042        : }
>Net::LDAP=HASH(0x80e4a44) received:
>
>30 0C 02 01 01 61 07 0A 01 00 04 00 04 00 __ __ 0....a........
>
>0000 30   12: SEQUENCE {
>0002 02    1:   INTEGER = 1
>0005 61    7:   [APPLICATION 1] {
>0007 0A    1:     ENUM = 0
>000A 04    0:     STRING = ''
>000C 04    0:     STRING = ''
>000E        :   }
>000E        : }
>Protocol error at ./getattrauth.pl line 31.
>[asr@rah perl]$ 
>
>End Failed session example -- 
>
>
>----- End forwarded message -----