Menu
▾
▴
perl-ldap-dev
|
From: Steve H. <ste...@ex...> - 2000-05-08 16:51:13
|
Hi, I'm having trouble with Net::LDAP 0.16 on Solaris (SunOS box 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10). It appears to compile fine, but I can't get the test suite to pass. I did some experimenting and got this (sorry about the hideous test command!): bash$ perl5.00503 -Iblib/lib -MNet::LDAP -MNet::LDAP::Util -MNet::LDAP::LDIF -e '$ldap = Net::LDAP->new(q[ldap0.london.excite.com], debug => 3); $br = $ldap->bind; $br->code && die q[bind: ].Net::LDAP::Util::ldap_error_text($br->code); $sr = $ldap->search(filter => q[(uid=shaslam)], base => q[ou=People,o=Excite,c=GB], attrs => [qw(cn)]); $sr->code && die q[search: ].Net::LDAP::Util::ldap_error_text($sr->code); $count = $sr->count; print qq[$sr, $count results\n]; $ldif = new Net::LDAP::LDIF(\*STDOUT, q[w]); $ldif->write($sr->entries)' Net::LDAP=HASH(0xc0a44) sending: 30 0C 02 01 01 60 07 02 01 02 04 00 80 00 __ __ 0....`........ bind: Server encountered an internal error ldap0.london.excite.com is running OpenLDAP 1.2.10 Similarly, when I try to run t/50populate, I get: 1..44 ok 1 #1 not ok 2 ok 3 ok 4 #1 which afaict means essentially the same thing. I get just the same results with Perl 5.6.0 as with 5.00503. Net::LDAP 0.13 works fine. On my Linux machine (Linux hell 2.2.14 #1-DellLatCPi Sun Mar 19 17:26:31 GMT 2000 i686 unknown) the same command gives: Net::LDAP=HASH(0x80cb8fc) received: 30 0C 02 01 01 61 07 0A 01 00 04 00 04 00 __ __ 0....a........ Net::LDAP=HASH(0x80cb8fc) sending: [more stuff...] instead of the bind error. Has anyone else had this? I don't know enough about the innards of Net::LDAP to know precisely where to look, but it returning an internal server error before receiving any data suggests there's a problem in the receiver select() loop? SRH -- Steve Haslam, Production Engineer, Excite UK ste...@ex... father, we're so close to death, you told us this time would come we were full of scorn, now we see the wrong deeds bloom you told us that we were wrong |
|
From: Steve H. <ste...@ex...> - 2000-05-08 17:05:08
|
On Mon, May 08, 2000 at 05:50:47PM +0100, Steve Haslam wrote:
> I'm having trouble with Net::LDAP 0.16 on Solaris (SunOS box 5.7
> Generic_106541-02 sun4u sparc SUNW,Ultra-5_10). It appears to compile
> fine, but I can't get the test suite to pass.
> Net::LDAP=HASH(0xc0a44) sending:
>
> 30 0C 02 01 01 60 07 02 01 02 04 00 80 00 __ __ 0....`........
>
> bind: Server encountered an internal error
Hm, using asn_read() instead of asn_recv() in Net/LDAP.pm seems to fix
it. Maybe (Solaris 7|my Perl installation) doesn't like using
MSG_PEEK?
SRH
--
Steve Haslam, Production Engineer, Excite UK ste...@ex...
there is no life worth living when you can't explore the mind
and all the losing souls will stay behind remaining blind
|
|
From: Steve H. <ste...@ex...> - 2000-05-08 17:19:52
Attachments:
07io.t
|
On Mon, May 08, 2000 at 06:04:40PM +0100, Steve Haslam wrote:
> On Mon, May 08, 2000 at 05:50:47PM +0100, Steve Haslam wrote:
> > I'm having trouble with Net::LDAP 0.16 on Solaris (SunOS box 5.7
> > Generic_106541-02 sun4u sparc SUNW,Ultra-5_10). It appears to compile
> > fine, but I can't get the test suite to pass.
> > Net::LDAP=HASH(0xc0a44) sending:
> >
> > 30 0C 02 01 01 60 07 02 01 02 04 00 80 00 __ __ 0....`........
> >
> > bind: Server encountered an internal error
>
> Hm, using asn_read() instead of asn_recv() in Net/LDAP.pm seems to fix
> it. Maybe (Solaris 7|my Perl installation) doesn't like using
> MSG_PEEK?
Attached is a version of t/07io.t from Convert::ASN1 that fails on my
machine until I change asn_recv to asn_read for the TCP socket...
SRH
--
Steve Haslam, Production Engineer, Excite UK ste...@ex...
there is no life worth living when you can't explore the mind
and all the losing souls will stay behind remaining blind
|
|
From: Graham B. <gb...@po...> - 2000-05-08 18:51:26
|
The problem is that on Solaris recv will not always return the address of the sender if the socket is connected. The fix for this is that in Net::LDAP where is uses asn_recv it should have a defined check on the result. The CVS respository on sourceforge has this fix. There is also a patch at http://download.sourceforge.net/perl-ldap Graham. On Mon, May 08, 2000 at 06:19:27PM +0100, Steve Haslam wrote: > On Mon, May 08, 2000 at 06:04:40PM +0100, Steve Haslam wrote: > > On Mon, May 08, 2000 at 05:50:47PM +0100, Steve Haslam wrote: > > > I'm having trouble with Net::LDAP 0.16 on Solaris (SunOS box 5.7 > > > Generic_106541-02 sun4u sparc SUNW,Ultra-5_10). It appears to compile > > > fine, but I can't get the test suite to pass. > > > Net::LDAP=HASH(0xc0a44) sending: > > > > > > 30 0C 02 01 01 60 07 02 01 02 04 00 80 00 __ __ 0....`........ > > > > > > bind: Server encountered an internal error > > > > Hm, using asn_read() instead of asn_recv() in Net/LDAP.pm seems to fix > > it. Maybe (Solaris 7|my Perl installation) doesn't like using > > MSG_PEEK? > > Attached is a version of t/07io.t from Convert::ASN1 that fails on my > machine until I change asn_recv to asn_read for the TCP socket... > > SRH > -- > Steve Haslam, Production Engineer, Excite UK ste...@ex... > there is no life worth living when you can't explore the mind > and all the losing souls will stay behind remaining blind |
|
From: Steve H. <ste...@ex...> - 2000-05-08 20:08:56
|
On Mon, May 08, 2000 at 07:49:24PM +0100, Graham Barr wrote: > The problem is that on Solaris recv will not always return the address > of the sender if the socket is connected. The fix for this is that > in Net::LDAP where is uses asn_recv it should have a defined check on the > result. > > The CVS respository on sourceforge has this fix. There is also a patch > at http://download.sourceforge.net/perl-ldap Ah, thanks... OK, I still get a problem with 0.16 over 0.13. I can't use $sr->shift_entry. I can do foreach $entry ($sr->entries) { ... } but not while ($entry = $sr->shift_entry) { ... } Hm, upon trying again, it did give me an entry but then blocked... According to truss it's blocking in recvfrom()... Also, sometimes I get the "$ldap received:" message and then no hex dump. Particularly if I'm requesting a large value (jpegPhoto attributes for instance). SRH -- Steve Haslam, Production Engineer, Excite UK ste...@ex... i sit and stare at the gun pointed at my head and think about all the possibilities |
|
From: Graham B. <gb...@po...> - 2000-05-08 20:30:07
|
On Mon, May 08, 2000 at 09:08:27PM +0100, Steve Haslam wrote: > On Mon, May 08, 2000 at 07:49:24PM +0100, Graham Barr wrote: > > The problem is that on Solaris recv will not always return the address > > of the sender if the socket is connected. The fix for this is that > > in Net::LDAP where is uses asn_recv it should have a defined check on the > > result. > > > > The CVS respository on sourceforge has this fix. There is also a patch > > at http://download.sourceforge.net/perl-ldap > > Ah, thanks... > > OK, I still get a problem with 0.16 over 0.13. I can't use > $sr->shift_entry. I can do > > foreach $entry ($sr->entries) { ... } > > but not > > while ($entry = $sr->shift_entry) { ... } > > Hm, upon trying again, it did give me an entry but then > blocked... According to truss it's blocking in recvfrom()... Well if the search is not complete and there are no entries in the queue then it will block for the next entry. > Also, sometimes I get the "$ldap received:" message and then no hex > dump. Particularly if I'm requesting a large value (jpegPhoto > attributes for instance). Hm, does this happen if you changed to using asn_read ? Graham. |
|
From: Steve H. <ste...@ex...> - 2000-05-08 20:40:36
|
On Mon, May 08, 2000 at 09:27:54PM +0100, Graham Barr wrote: > On Mon, May 08, 2000 at 09:08:27PM +0100, Steve Haslam wrote: > > On Mon, May 08, 2000 at 07:49:24PM +0100, Graham Barr wrote: > > Hm, upon trying again, it did give me an entry but then > > blocked... According to truss it's blocking in recvfrom()... > > Well if the search is not complete and there are no entries in the queue > then it will block for the next entry. But the search *is* complete- in a test case it's returned the one entry it should and then blocked... Hm, I didn't check whether the server had logged it as being complete... OK, I'm doing: bash$ perl5.00503 -Iblib/lib -l -MData::Dumper -MNet::LDAP -MNet::LDAP::LDIF -e '$ldap = Net::LDAP->new(q[ldap0.london.excite.com], debug => 3); $ldap->bind; $sr = $ldap->search(filter => q[(uid=shaslam)], base => q[ou=people, o=excite, c=gb], attrs => [qw(cn)]); while ($entry = $sr->shift_entry) { print $entry->dn; }' and I get: Net::LDAP=HASH(0xc0a44) sending: 30 0C 02 01 01 60 07 02 01 02 04 00 80 00 __ __ 0....`........ Net::LDAP=HASH(0xc0a44) received: 30 0C 02 01 01 61 07 0A 01 00 04 00 04 00 __ __ 0....a........ Net::LDAP=HASH(0xc0a44) sending: 30 45 02 01 02 63 40 04 19 6F 75 3D 70 65 6F 70 0E...c@..ou=peop 6C 65 2C 20 6F 3D 65 78 63 69 74 65 2C 20 63 3D le, o=excite, c= 67 62 0A 01 02 0A 01 02 02 01 00 02 01 00 01 01 gb.............. 00 A3 0E 04 03 75 69 64 04 07 73 68 61 73 6C 61 .....uid..shasla 6D 30 04 04 02 63 6E __ __ __ __ __ __ __ __ __ m0...cn Net::LDAP=HASH(0xc0a44) received: 30 45 02 01 02 64 40 04 26 75 69 64 3D 73 68 61 0E...d@.&uid=sha 73 6C 61 6D 2C 20 6F 75 3D 50 65 6F 70 6C 65 2C slam, ou=People, 20 6F 3D 45 78 63 69 74 65 2C 20 63 3D 47 42 30 o=Excite, c=GB0 16 30 14 04 02 63 6E 31 0E 04 0C 53 74 65 76 65 .0...cn1...Steve 20 48 61 73 6C 61 6D __ __ __ __ __ __ __ __ __ Haslam Net::LDAP=HASH(0xc0a44) received: 30 0C 02 01 02 65 07 0A 01 00 04 00 04 00 __ __ 0....e........ uid=shaslam, ou=People, o=Excite, c=GB and it blocks, and the server log contains: May 8 21:35:48 vertex slapd[28859]: conn=789 fd=7 connection from box.london.excite.com (194.216.238.12) accepted. May 8 21:35:48 vertex slapd[9067]: conn=789 op=0 BIND dn="" method=128 May 8 21:35:48 vertex slapd[9067]: conn=789 op=0 RESULT err=0 tag=97 nentries=0 May 8 21:35:48 vertex slapd[9068]: conn=789 op=1 SRCH base="OU=PEOPLE,O=EXCITE,C=GB" scope=2 filter="(uid=SHASLAM)" May 8 21:35:48 vertex slapd[9068]: conn=789 op=1 RESULT err=0 tag=101 nentries=1 I hit C-c and it logs: May 8 21:36:09 vertex slapd[28859]: conn=789 op=-1 fd=7 closed errno=0 > > Also, sometimes I get the "$ldap received:" message and then no hex > > dump. Particularly if I'm requesting a large value (jpegPhoto > > attributes for instance). > > Hm, does this happen if you changed to using asn_read ? If I change asn_recv to asn_read then it hangs before printing that "$ldap received:" message. SRH -- Steve Haslam, Production Engineer, Excite UK ste...@ex... father, we're so close to death, you told us this time would come we were full of scorn, now we see the wrong deeds bloom you told us that we were wrong |
|
From: Graham B. <gb...@po...> - 2000-05-08 21:09:53
|
On Mon, May 08, 2000 at 09:40:09PM +0100, Steve Haslam wrote: > On Mon, May 08, 2000 at 09:27:54PM +0100, Graham Barr wrote: > > On Mon, May 08, 2000 at 09:08:27PM +0100, Steve Haslam wrote: > > > On Mon, May 08, 2000 at 07:49:24PM +0100, Graham Barr wrote: > > > Hm, upon trying again, it did give me an entry but then > > > blocked... According to truss it's blocking in recvfrom()... > > > > Well if the search is not complete and there are no entries in the queue > > then it will block for the next entry. > > But the search *is* complete- in a test case it's returned the one > entry it should and then blocked... > > Hm, I didn't check whether the server had logged it as being complete... > > OK, I'm doing: > > bash$ perl5.00503 -Iblib/lib -l -MData::Dumper -MNet::LDAP -MNet::LDAP::LDIF -e '$ldap = Net::LDAP->new(q[ldap0.london.excite.com], debug => 3); $ldap->bind; $sr = $ldap->search(filter => q[(uid=shaslam)], base => q[ou=people, o=excite, c=gb], attrs => [qw(cn)]); while ($entry = $sr->shift_entry) { print $entry->dn; }' OK, in this case the search has completed. Hm, it should return undef after the one entry. > > > Also, sometimes I get the "$ldap received:" message and then no hex > > > dump. Particularly if I'm requesting a large value (jpegPhoto > > > attributes for instance). > > > > Hm, does this happen if you changed to using asn_read ? > > If I change asn_recv to asn_read then it hangs before printing that > "$ldap received:" message. Is that with the patch from sourceforge ? Hm, that is because asn_recv is returning too early, but asn_read is waiting for more data. THis is exactly whay someone else reported on NT. The server says that it has sent the data. Now we know it is not platform specific. If anyone can help track this one down I would be very grateful as I have been unable to reproduce it. Graham. |
|
From: Pythagoras W. <py...@ec...> - 2000-05-09 05:41:10
Attachments:
ldapmiddleman
LDAP_pm_patch
|
On Mon, May 08, 2000 at 10:07:48PM +0100, Graham Barr wrote:
:On Mon, May 08, 2000 at 09:40:09PM +0100, Steve Haslam wrote:
:> On Mon, May 08, 2000 at 09:27:54PM +0100, Graham Barr wrote:
:> > On Mon, May 08, 2000 at 09:08:27PM +0100, Steve Haslam wrote:
:> > > Also, sometimes I get the "$ldap received:" message and then no hex
:> > > dump. Particularly if I'm requesting a large value (jpegPhoto
:> > > attributes for instance).
:> >
:> > Hm, does this happen if you changed to using asn_read ?
:>
:> If I change asn_recv to asn_read then it hangs before printing that
:> "$ldap received:" message.
:
:Is that with the patch from sourceforge ?
:
:Hm, that is because asn_recv is returning too early, but asn_read is waiting
:for more data. THis is exactly whay someone else reported on NT. The
:server says that it has sent the data.
:
:Now we know it is not platform specific.
:
:If anyone can help track this one down I would be very grateful as I
:have been unable to reproduce it.
I have attached a script that can be used to cause this problem.
Basically, the script sits between your client and the LDAP server.
Client requests are sent to the server. Server responses are sent to
the client, but are split into small packets that arrive slowly. This
causes asn_recv() to enter this "if" statement:
74 if ($len > length $buf) {
75 # Cannot get whole element
76 $_[1]='';
77 return $peer;
78 }
In my test, I ended up with a "$len=14", but "length $buf = 2".
Since $peer is defined, the call to asn_recv in LDAP.pm succeeds:
571 defined asn_recv($sock, $pdu, 0)
but $pdu is the empty string (from the "$_[1]=''" above). The debug
code happily prints out nothing but the "$ldap received:" message [1],
and then the call to decode:
586 my $result = $LDAPResponse->decode($pdu)
fails causing an LDAP_DECODING_ERROR to be returned:
572 or return LDAP_OPERATIONS_ERROR;
Normally, this is hard to notice, since packets usually arrive before
they need to be processed and/or an "LDAP" packet is completely
contained in a TCP packet. Note the openldap's ldapsearch does
succeed even with the really small buffer size of two.
Also, asn_recv goes into an infinite loop if you uncomment the XXX
line in my script. With warnings on it prints:
Use of uninitialized value at \
/opt/perl/lib/site_perl/5.00557/Convert/ASN1/IO.pm line 45.
Out of memory!
-Py
[1] See the attached patch for a minor recommendation that might have
made this a bit more obvious to notice.
--
Py (Amateur Radio: KF6WFP) -- 3.141592653589793238462643383...
Pythagoras Watson -- "Live long and may all your kernels pop."
=== py...@cs... ==== http://www.ecst.csuchico.edu/~py/ ===
|
|
From: Graham B. <gb...@po...> - 2000-05-09 08:00:11
|
On Mon, May 08, 2000 at 10:40:44PM -0700, Pythagoras Watson wrote:
> I have attached a script that can be used to cause this problem.
> Basically, the script sits between your client and the LDAP server.
> Client requests are sent to the server. Server responses are sent to
> the client, but are split into small packets that arrive slowly. This
> causes asn_recv() to enter this "if" statement:
> 74 if ($len > length $buf) {
> 75 # Cannot get whole element
> 76 $_[1]='';
> 77 return $peer;
> 78 }
While I would agree that this would cause the problem with asn_recv, it does
not explain why scripts hang when we use asn_read instead of asn_recv.
If I could fix that I would just change back to using read instead
of recv which is what previous versions of Net::LDAP use.
Graham.
PS: Thanks for the patch.
|
|
From: Chris R. <Chr...@me...> - 2000-05-09 08:13:44
|
On Tue, 09 May 2000 07:49:30 BST, Graham Barr wrote:
> On Mon, May 08, 2000 at 10:40:44PM -0700, Pythagoras Watson wrote:
> > I have attached a script that can be used to cause this problem.
> > Basically, the script sits between your client and the LDAP server.
> > Client requests are sent to the server. Server responses are sent to
> > the client, but are split into small packets that arrive slowly. This
> > causes asn_recv() to enter this "if" statement:
> > 74 if ($len > length $buf) {
> > 75 # Cannot get whole element
> > 76 $_[1]='';
> > 77 return $peer;
> > 78 }
>
> While I would agree that this would cause the problem with asn_recv, it does
> not explain why scripts hang when we use asn_read instead of asn_recv.
>
> If I could fix that I would just change back to using read instead
> of recv which is what previous versions of Net::LDAP use.
That would certainly make it easier to get LDAPS working again...
Chris
|
|
From: Graham B. <gb...@po...> - 2000-05-09 16:12:23
|
On Tue, May 09, 2000 at 09:10:55AM +0100, Chris Ridd wrote:
> On Tue, 09 May 2000 07:49:30 BST, Graham Barr wrote:
> > On Mon, May 08, 2000 at 10:40:44PM -0700, Pythagoras Watson wrote:
> > > I have attached a script that can be used to cause this problem.
> > > Basically, the script sits between your client and the LDAP server.
> > > Client requests are sent to the server. Server responses are sent to
> > > the client, but are split into small packets that arrive slowly. This
> > > causes asn_recv() to enter this "if" statement:
> > > 74 if ($len > length $buf) {
> > > 75 # Cannot get whole element
> > > 76 $_[1]='';
> > > 77 return $peer;
> > > 78 }
> >
> > While I would agree that this would cause the problem with asn_recv, it does
> > not explain why scripts hang when we use asn_read instead of asn_recv.
> >
> > If I could fix that I would just change back to using read instead
> > of recv which is what previous versions of Net::LDAP use.
>
> That would certainly make it easier to get LDAPS working again...
Hint, hint.
OK, I have changed it. The latest is available from the sourceforge
CVS, see http://sourceforge.net/cvs/?group_id=5050
You will also need the latest Convert::ASN (also on sourceforge) as this
highlighted a problem.
Graham.
|
|
From: Pythagoras W. <py...@ec...> - 2000-05-10 08:47:35
|
On Tue, May 09, 2000 at 05:10:16PM +0100, Graham Barr wrote: :CVS, see http://sourceforge.net/cvs/?group_id=5050 : :You will also need the latest Convert::ASN (also on sourceforge) :as this highlighted a problem. Looks good. My previously failing tests all pass now. -- Py (Amateur Radio: KF6WFP) -- 3.141592653589793238462643383... Pythagoras Watson -- "Live long and may all your kernels pop." === py...@cs... ==== http://www.ecst.csuchico.edu/~py/ === |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X