Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Convert-ASN1 CPAN distribution.

Report information
The Basics
Id: 13077
Status: resolved
Priority: 0/
Queue: Convert-ASN1
People
Owner: Nobody in particular
Requestors: anmayes [...] gmail.com
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Fri Jun 03 12:41:44 2005 anmayes [...] gmail.com - Ticket created
Date: Fri, 3 Jun 2005 11:34:54 -0500
From: Anthony Mayes <anmayes [...] gmail.com>
To: bugs-Convert-ASN1 [...] rt.cpan.org
Subject: decode error 00<=>30
I'm not sure if this is a bug or not but I thought I would ask. I am doing a search on an Active Directory system with net::ldap. I can search several OU's ranging in size from 200 to 2000. The problem occurs when I search an OU with over 12000 users in it. I get the following error: decode error 00<=>30 at /usr/perl5/site_perl/5.6.1/Convert/ASN1/_decode.pm line 110, <DATA> line 283. The version of Convert::ASN1 I am using is 0.18. Any ideas? Thanks, Anthony
  Fri Jun 03 14:06:56 2005 gbarr [...] pobox.com - Correspondence added
Date: Fri, 3 Jun 2005 12:52:51 -0500 (CDT)
Subject: Re: [cpan #13077] decode error 00<=>30
From: "Graham Barr" <gbarr [...] pobox.com>
To: bug-Convert-ASN1 [...] rt.cpan.org
RT-Send-Cc:
On Fri, June 3, 2005 11:41 am, Anthony Mayes via RT said: Show quoted text
> > I'm not sure if this is a bug or not but I thought I would ask. > > I am doing a search on an Active Directory system with net::ldap. > > I can search several OU's ranging in size from 200 to 2000. The > problem occurs when I search an OU with over 12000 users in it. I get > the following error: > > decode error 00<=>30 at > /usr/perl5/site_perl/5.6.1/Convert/ASN1/_decode.pm line 110, <DATA> > line 283. > > The version of Convert::ASN1 I am using is 0.18. Any ideas?
Can you try with 0.19 The 00 there make me think there is an indefinite-length involved. There is a bugfix in 0.19 for indefinite-length Graham.
  Mon Jun 06 10:43:11 2005 gbarr [...] pobox.com - Correspondence added
Date: Mon, 6 Jun 2005 09:28:52 -0500 (CDT)
Subject: Re: [Comment] Re: [cpan #13077] decode error 00<=>30
From: "Graham Barr" <gbarr [...] pobox.com>
To: bug-Convert-ASN1 [...] rt.cpan.org
RT-Send-Cc:
On Mon, June 6, 2005 9:36 am, Anthony Mayes via RT said: Show quoted text
> Thanks for the tip. Unfortunately that didn't do it. After I > installed 0.19 the error changed to: > > decode error 00<=>30 0 8 at > /usr/perl5/site_perl/5.6.1/Convert/ASN1/_decode.pm line 111, <DATA> > line 283. > > Could this possibly be an Active Directory problem?
I would not jump to any conclusions yet. Can you turn on packet tracing by adding $ldap->debug(10); Just before the crash location in your script. And send whats is put on STDERR Graham.
  Mon Jun 06 15:18:45 2005 gbarr [...] pobox.com - Correspondence added
Date: Mon, 6 Jun 2005 14:04:28 -0500 (CDT)
Subject: Re: [Comment] Re: Re: [cpan #13077] decode error 00<=>30
From: "Graham Barr" <gbarr [...] pobox.com>
To: bug-Convert-ASN1 [...] rt.cpan.org
RT-Send-Cc:
On Mon, June 6, 2005 2:01 pm, Anthony Mayes via RT said: Show quoted text
> This message about Convert-ASN1 was sent to you by anmayes@gmail.com via > rt.cpan.org > > Full context and any attached attachments can be found at: > <URL: https://rt.cpan.org/Ticket/Display.html?id=13077 > > > This is a comment. It is not sent to the Requestor(s): > > All I get is a 0. This is what the code looks like: > > $mesg = $ldap->search(base=>"OU=$ou,OU=Users,DC=siue,DC=edu", > filter=>"(sAMAccountName=*)", > sizelimit=>"0", > attrs=>['cn', 'sn', 'givenName', > 'distinguishedName', > 'displayName', 'name', > 'homeDirectory', 'sAMAccountName', > 'userPrincipalName', 'mail', > 'loginScript']); > > $entries = $mesg->count; > $ldap_error_code = $mesg->code; > $ldap_error_message = $mesg->error; > > $ldap_debug_message = $ldap->debug(10);
It is not the return from the method that is important. Calling this method should cause a lot og debug to be sent to STDERR showing the packets that the server is sending us. I need to see the packet contents do determine if this is a bug on Convert::ASN1 or if it is bad data from the server. Graham. Show quoted text
> print "ldap_debug_message: $ldap_debug_message\n"; > > print "ldap_error_code: $ldap_error_code\t ldap_error_message: > $ldap_error_message\n"; > die $mesg->error if $mesg->code; > > > Thanks > > > On 6/6/05, Graham Barr via RT <comment-Convert-ASN1@rt.cpan.org> wrote:
>> Full context and any attached attachments can be found at: >> <URL: http://rt.cpan.org/NoAuth/Bug.html?id=13077 > >> >> On Mon, June 6, 2005 9:36 am, Anthony Mayes via RT said:
>> > Thanks for the tip. Unfortunately that didn't do it. After I >> > installed 0.19 the error changed to: >> > >> > decode error 00<=>30 0 8 at >> > /usr/perl5/site_perl/5.6.1/Convert/ASN1/_decode.pm line 111, <DATA> >> > line 283. >> > >> > Could this possibly be an Active Directory problem?
>> >> I would not jump to any conclusions yet. >> >> Can you turn on packet tracing by adding >> >> $ldap->debug(10); >> >> Just before the crash location in your script. And send >> whats is put on STDERR >> >> Graham. >> >> >>
> > > -- > Anthony Mayes > UNIX Server Administration > Southern Illinois University Edwardsville > anmayes at siue dot edu > anmayes at gmail dot com > > >
  Mon Jun 06 19:31:41 2005 gbarr [...] pobox.com - Correspondence added
From: Graham Barr <gbarr [...] pobox.com>
Subject: Re: [Comment] Re: Re: Re: [cpan #13077] decode error 00<=>30
Date: Mon, 6 Jun 2005 18:31:16 -0500
To: bug-Convert-ASN1 [...] rt.cpan.org
RT-Send-Cc:
On Jun 6, 2005, at 3:50 PM, Anthony Mayes via RT wrote: Show quoted text
> > This is the last few sections before the error:
This seems very strange. I was expecting to see the error was in the middle of a packet. But Show quoted text
> 30 84 00 00 01 FB 02 01 03 64 84 00 00 01 F2 04 0........d...... > 3C 43 4E 3D 6A 65 73 6B 65 72 2C 4F 55 3D 53 74 <CN=jesker,OU=St
This starts with 30, which is correct. The 01 FB is the packet length and what I counted was right Show quoted text
> 30 84 00 00 02 05 02 01 03 64 84 00 00 01 FC 04 0........d...... > 3D 43 4E 3D 6A 65 73 6C 6F 77 65 2C 4F 55 3D 53 =CN=jeslowe,OU=S
Again, starts with 30 and the length was 0205 Show quoted text
> 00 84 00 00 01 FB 02 01 03 64 84 00 00 01 F2 04 .........d...... > 3C 43 4E 3D 6A 65 73 6D 6F 6E 2C 4F 55 3D 53 74 <CN=jesmon,OU=St
Now this is where it gets weird. We have 00 instead of 30 but the rest looks OK. Even the length of 01 FB is ok. I was expecting to find I had read the packet boundaries wrong, but it looks like there is bad data in the stream. So this is looking more like a server bug. But before we declare that we need to insure that my read code did not do something weird. I see you are using LDAPS, is it possible to reproduce this by just using LDAP. Then use tcpdump or something to watch the network interface I just want to be sure it is not a bug in my code before telling you to talk to the server vendor. Other things to look at/try Are you running the latest IO::Socket::SSL Net::SSLeay code ? Can you run the ldapsearch command line utility with the same search ? Graham.
  Wed Jun 29 10:31:44 2005 Guest - Correspondence added
From: etienne.guerin [...] bt.com
[gbarr@pobox.com - Mon Jun 6 19:31:41 2005]: Show quoted text
> On Jun 6, 2005, at 3:50 PM, Anthony Mayes via RT wrote:
> > > > This is the last few sections before the error:
> > This seems very strange. I was expecting to see the error was > in the middle of a packet. But >
> > 30 84 00 00 01 FB 02 01 03 64 84 00 00 01 F2 04 0........d...... > > 3C 43 4E 3D 6A 65 73 6B 65 72 2C 4F 55 3D 53 74 <CN=jesker,OU=St
> > This starts with 30, which is correct. The 01 FB is the packet length > and what I counted was right >
> > 30 84 00 00 02 05 02 01 03 64 84 00 00 01 FC 04 0........d...... > > 3D 43 4E 3D 6A 65 73 6C 6F 77 65 2C 4F 55 3D 53 =CN=jeslowe,OU=S
> > Again, starts with 30 and the length was 0205 >
> > 00 84 00 00 01 FB 02 01 03 64 84 00 00 01 F2 04 .........d...... > > 3C 43 4E 3D 6A 65 73 6D 6F 6E 2C 4F 55 3D 53 74 <CN=jesmon,OU=St
> > Now this is where it gets weird. We have 00 instead of 30 but the rest > looks OK. Even the length of 01 FB is ok. > > I was expecting to find I had read the packet boundaries wrong, > but it looks like there is bad data in the stream. > > So this is looking more like a server bug. But before we declare that > we need to insure that my read code did not do something weird. > > I see you are using LDAPS, is it possible to reproduce this by just > using LDAP. Then use tcpdump or something to watch the network > interface > > I just want to be sure it is not a bug in my code before telling you > to talk to the server vendor. > > Other things to look at/try > > Are you running the latest IO::Socket::SSL Net::SSLeay code ? > > Can you run the ldapsearch command line utility with the same search ? > > Graham. >
I have exactly the same problem using the latest IO::Socket::SSL and Net::SSLeay code. I can run the ldapsearch command line utility with the same search. Did you find a solution ? Thanks Etienne
  Fri Jun 08 19:24:52 2012 GBARR [...] CPAN.ORG - Status changed from 'new' to 'resolved'