As I mentioned in a slightly earlier email, I am using the control
Net::LDAP::Control::Paged

I have just noticed a difference in the debug output for the last
record decoded:

After the Hex:
Net::LDAPS=HASH(0x1df866c) received:

00 84 00 00 02 73 02 01 71 64 84 00 00 02 6A 04 .....s..qd....j.
(etc...)

The ASN.1 starts with:

0000  627: [UNIVERSAL 0]
0006 : 02 01 71 64 84 00 00 02 6A 04 66 43 4E 3D 44 4C ..qd....j.fCN=DL

The [UNIVERSAL 0] is different, all previous records looked like:

0000  688: SEQUENCE {
0006    1:   INTEGER = 113
0009  679:   [APPLICATION 4] {


So instead of starting "30 84 00 00" the bad record
starts  "00 84 00 00".

Does this make any sense?

Cheers

Si




Chris Ridd wrote:
On 15/5/06 11:55, Si Smith <[EMAIL PROTECTED]> wrote:

Hi,

I am using Perl-ldap ( and excellent it is too ) to connect
to an Active Directory.  I am using an SSL connection since
I do not want to pass the password in the clear.

When reading a large sub-tree, in a number of pages, I get this
error ( LDAP_DECODING_ERROR:C<Net::LDAP> ). If I change the page
size it occurs after a different number of entries.

e.g Page size 250 - after 20250 entries
               50  - after 5400 entries

If I make the connection without SSL there is no problem and
all the records can be read without sign of the decoding error.

Any clues anyone.

What sort of control are you using to get these results? We might have got
something wrong in there, like getting confused about byte/utf8. You could
try calling debug(15) to get hex dumps of all the result packets to see
what's different about the failing one.

Alternatively (worst case scenario) I wonder if something's happening at the
SSL level which we're (or IO::Socket::SSL or Net::SSLeay are) not dealing
with properly. If you don't get any insights from the debug output above,
can you attach a network sniffer like Ethereal and see anything interesting
happening around the times both connections go bad?

Cheers,

Chris


Reply via email to