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. |