On 14/3/05 3:39 pm, Lee Jensen <[EMAIL PROTECTED]> wrote:
> I posted to the LDAP software list to find more information on this and
> also enabled more debugging in my ldap server. It seems that there is a
> bug of sorts that requires that content sync controls have the critical
> flag set to 0. So I did this and the server is responding as expected
> now. However a new problem has arisen.
>
> It seems that the perl client is unable to decode the message(s) sent
> back from the server.
>
> Here is the full debug output:
>
>> perl persist_search.pl
> 0
> \uffff
> Net::LDAP=HASH(0x831532c) sending:
>
> BIND DEBUGGING REMOVED
>
> Success
> DOING SEARCH
> Net::LDAP=HASH(0x831532c) sending:
>
> 30 81 A0 02 01 02 63 73 04 1C 64 63 3D 64 69 72 0.....cs..dc=dir
> 65 63 74 6F 72 79 2C 64 63 3D 73 65 6E 74 6F 2C ectory,dc=sento,
> 64 63 3D 63 6F 6D 0A 01 02 0A 01 00 02 01 00 02 dc=com..........
> 01 00 01 01 00 A3 11 04 03 75 69 64 04 0A 6C 65 .........uid..le
> 65 5F 6A 65 6E 73 65 6E 30 31 04 01 2A 04 0B 6F e_jensen01..*..o
> 62 6A 65 63 74 43 6C 61 73 73 04 15 73 74 72 75 bjectClass..stru
> 63 74 75 72 61 6C 4F 62 6A 65 63 74 43 6C 61 73 cturalObjectClas
> 73 04 08 65 6E 74 72 79 43 53 4E A0 26 30 24 04 s..entryCSN.&0$.
> 18 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 34 32 30 .1.3.6.1.4.1.420
> 33 2E 31 2E 39 2E 31 2E 31 04 08 30 06 0A 01 03 3.1.9.1.1..0....
> 01 01 FF __ __ __ __ __ __ __ __ __ __ __ __ __ ...
>
> 0000 160: SEQUENCE {
> 0003 1: INTEGER = 2
> 0006 115: [APPLICATION 3] {
> 0008 28: STRING = 'dc=directory,dc=sento,dc=com'
> 0026 1: ENUM = 2
> 0029 1: ENUM = 0
> 002C 1: INTEGER = 0
> 002F 1: INTEGER = 0
> 0032 1: BOOLEAN = FALSE
> 0035 17: [CONTEXT 3] {
> 0037 3: STRING = 'uid'
> 003C 10: STRING = 'lee_jensen'
> 0048 : }
> 0048 49: SEQUENCE {
> 004A 1: STRING = '*'
> 004D 11: STRING = 'objectClass'
> 005A 21: STRING = 'structuralObjectClass'
> 0071 8: STRING = 'entryCSN'
> 007B : }
> 007B : }
> 007B 38: [CONTEXT 0] {
> 007D 36: SEQUENCE {
> 007F 24: STRING = '1.3.6.1.4.1.4203.1.9.1.1'
> 0099 8: STRING
> 009B : 30 06 0A 01 03 01 01 FF __ __ __ __ __ __ __ __
> 0.......
> 00A3 : }
> 00A3 : }
> 00A3 : }
> Net::LDAP=HASH(0x831532c) received:
>
> FULL ENTRY INFORMATION REMOVED FOR SPACE
>
> Net::LDAP=HASH(0x831532c) received:
>
> 30 49 02 01 02 79 44 8A 18 31 2E 33 2E 36 2E 31 0I...yD..1.3.6.1
> 2E 34 2E 31 2E 34 32 30 33 2E 31 2E 39 2E 31 2E .4.1.4203.1.9.1.
> 34 8B 28 A2 26 04 24 63 73 6E 3D 32 30 30 35 30 4.(.&.$csn=20050
> 33 31 31 32 32 31 36 35 39 5A 23 30 30 30 30 30 311221659Z#00000
> 31 23 30 30 23 30 30 30 30 30 30 __ __ __ __ __ 1#00#000000
>
> 0000 73: SEQUENCE {
> 0002 1: INTEGER = 2
> 0005 68: [APPLICATION 25] {
> 0007 24: [CONTEXT 10]
> 0009 : 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 34 32 30 33
> 1.3.6.1.4.1.4203
> 0019 : 2E 31 2E 39 2E 31 2E 34 __ __ __ __ __ __ __
> __ .1.9.1.4
> 0021 40: [CONTEXT 11]
> 0023 : A2 26 04 24 63 73 6E 3D 32 30 30 35 30 33 31
> 31 .&.$csn=20050311
> 0033 : 32 32 31 36 35 39 5A 23 30 30 30 30 30 31 23 30
> 221659Z#000001#0
> 0043 : 30 23 30 30 30 30 30 30 __ __ __ __ __ __ __ __
> 0#000000
> 004B : }
> 004B : }
> PAST SEARCH
> decode error
> at /usr/local/lib/perl5/site_perl/5.8.6/Convert/ASN1/_decode.pm line
> 230, <DATA> line 461.
This is using some ASN.1 from RFC 3771, which isn't currently implemented by
Net::LDAP.
> If anyone has some knowledge of the modules internals and could perhaps
> give a cursory overview of how to modify it to accept these kind of
> response messages I would appreciate it. Also in this refresh and
> persist mode the server responds with a control for every entry
> returned. Could the entry class be made to inherit from the message
> class so controls can be retrieved from it?
You may want to look at putting definitions of IntermediateResponse (etc)
into Net/LDAP/ASN.pm.
I'm not sure what other changes you'll need to make to Net::LDAP to get
those responses through to the caller, but being able to decode the things
would seem to be a good start.
Cheers,
Chris
