[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ASN1 - syncInfoValue
At 09:57 AM 3/16/2005, Lee Jensen wrote:
>I figured out my problem from yesterday... It seems the decoding
>specification I was using did not set the certain boolean elements to
>optional so they were expected and the decoding did not work properly.
Note that OPTIONAL != DEFAULT FALSE.
I suggest you look at how DEFAULT FALSE is handled elsewhere in
net::ldap. Such ASN.1 constructions are common in LDAP.
>I have another issue. I am essentially just wondering essentially how
>are the syncUUIDs encoded?
Each syncUUID is a OCTET STRING of size 16. So, the
its encoded as 04 10 followed by the 16 octets of the UUID.
>When I try to print out the decoded OCTET
>STRINGS they are not standard ascii or utf-8 characters.
You cannot just print the UUID as its octets are not character
data. You need to encode them (using say the UUID string
format) before printing.
>Here is a dump
>of an intermediate response message. (seems the same as the last one I
>posted)
>
>30 81 92 02 01 02 79 81 8C 8A 18 31 2E 33 2E 36 0.....y....1.3.6
>2E 31 2E 34 2E 31 2E 34 32 30 33 2E 31 2E 39 2E .1.4.1.4203.1.9.
>31 2E 34 8B 70 A3 6E 31 6C 04 10 40 59 47 D0 23 1.4.p.n1l..@YG.#
>7A 10 29 91 2A 90 61 61 9A 89 0B 04 10 D2 80 A8 z.).*.aa........
>BA 25 FA 10 29 8E 95 94 C1 3F CB 53 CE 04 10 9B .%..)....?.S....
>33 A5 F2 26 C1 10 29 9E 3A E7 B7 04 1D 82 48 04 3..&..).:.....H.
>10 F5 52 BF 82 26 C1 10 29 9E 3B E7 B7 04 1D 82 ..R..&..).;.....
>48 04 10 5C 6D 13 D4 26 C2 10 29 9E 3C E7 B7 04 H..\m..&..).<...
>1D 82 48 04 10 D4 BE C4 3E 26 C4 10 29 92 95 DC ..H.....>&..)...
>CB 4F 43 CF 50 __ __ __ __ __ __ __ __ __ __ __ .OC.P
>
>I'm not sure how to translate elements of the set of syncUUIDS into
>something I can use. Are they base64 encoded or what??
You actually should store them as an 16-octet value
and compare them to the 16-octet value **represented by**
the entryUUID value. That is,
do NOT:
compare(uuid2str(syncuuid), entryuuid))
do:
compare(syncuuid, str2uuid(entryuuid))
as a single UUID has multiple possible string representations.
That is, follow the general rule that comparisons in LDAP are
to be done between abstract values, not physical representations
of those abstract values.
Kurt
>Thanks for all your help.
>
>Lee Jensen
>
>On Tue, 2005-03-15 at 13:40 -0800, Kurt D. Zeilenga wrote:
>> At 01:08 PM 3/15/2005, Lee Jensen wrote:
>> >On Tue, 2005-03-15 at 12:59 -0800, Kurt D. Zeilenga wrote:
>> >> I not familiar with net::ldap debugging statements to know
>> >> what's really happen underneath. Suggest you provide a
>> >> hex dump of the whole PDU. Off hand, it looks like the
>> >> ending SET OF syncUUID is missing, possibly an empty set
>> >> (31 00).
>> >>
>> >
>> >Well the debugging is actually from Convert::ASN1 but here is the hex
>> >dump anyway:
>> >
>> >30 81 92 02 01 02 79 81 8C 8A 18 31 2E 33 2E 36 0.....y....1.3.6
>> >2E 31 2E 34 2E 31 2E 34 32 30 33 2E 31 2E 39 2E .1.4.1.4203.1.9.
>> >31 2E 34 8B 70 A3 6E 31 6C 04 10 40 59 47 D0 23 1.4.p.n1l..@YG.#
>> >7A 10 29 91 2A 90 61 61 9A 89 0B 04 10 D2 80 A8 z.).*.aa........
>> >BA 25 FA 10 29 8E 95 94 C1 3F CB 53 CE 04 10 9B .%..)....?.S....
>> >33 A5 F2 26 C1 10 29 9E 3A E7 B7 04 1D 82 48 04 3..&..).:.....H.
>> >10 F5 52 BF 82 26 C1 10 29 9E 3B E7 B7 04 1D 82 ..R..&..).;.....
>> >48 04 10 5C 6D 13 D4 26 C2 10 29 9E 3C E7 B7 04 H..\m..&..).<...
>> >1D 82 48 04 10 D4 BE C4 3E 26 C4 10 29 92 95 DC ..H.....>&..)...
>> >CB 4F 43 CF 50 __ __ __ __ __ __ __ __ __ __ __ .OC.P
>>
>> This looks okay to me. The SyncInfoValue.syncIdSet has no
>> cookie (its OPTIONAL), no refreshDeletes (its the DEFAULT),
>> and a non-empty SET OF syncUUIDs.
>>
>> >AND
>> >
>> >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 35 31 36 33 33 33 30 5A 23 30 30 30 30 30 315163330Z#00000
>> >31 23 30 30 23 30 30 30 30 30 30 __ __ __ __ __ 1#00#000000
>>
>> This looks okay to me as well. The SyncInfoValue.refreshPresent
>> has a cookie and no refreshDeletes (its the DEFAULT).
>>
>>
>>
>> >Thanks for your help Kurt,
>> >
>> >Lee
>> >
>> >> Kurt
>> >>
>> >> At 08:58 AM 3/15/2005, Lee Jensen wrote:
>> >> >I am attempting to modify the Net::LDAP module for perl to understand
>> >> >openLDAP's content synchronization controls (syncrepl functionality).
>> >> >
>> >> >I am currently able to use refresh and persist mode and retrieve the
>> >> >cookies/controls that come back with each result but I am having a
>> >> >problem with the syncInfoMessage. It's an intermediate message as
>> >> >defined in the RFC.
>> >> >http://www.ietf.org/internet-drafts/draft-zeilenga-ldup-sync-06.txt
>> >> >
>> >> >My question is this... In the RFC the syncInfoValue is defined as
>> >> >follows:
>> >> > syncInfoValue ::= CHOICE {
>> >> > newcookie [0] syncCookie,
>> >> > refreshDelete [1] SEQUENCE {
>> >> > cookie syncCookie OPTIONAL,
>> >> > refreshDone BOOLEAN DEFAULT TRUE
>> >> > },
>> >> > refreshPresent [2] SEQUENCE {
>> >> > cookie syncCookie OPTIONAL,
>> >> > refreshDone BOOLEAN DEFAULT TRUE
>> >> > },
>> >> > syncIdSet [3] SEQUENCE {
>> >> > cookie syncCookie OPTIONAL,
>> >> > refreshDeletes BOOLEAN DEFAULT FALSE,
>> >> > syncUUIDs SET OF syncUUID
>> >> > }
>> >> > }
>> >> >
>> >> >I have code to enable Net::LDAP::ASN to parse this specification but
>> >> >something just doesn't seem quite right. I can't tell if there is a
>> >> >problem with the ASN decoder or what. I get 2 seemingly different
>> >> >messages coming back when I do dumps...
>> >> >
>> >> >THIS which comes back if I connect with no cookie:
>> >> >
>> >> >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
>> >35 .&.$csn=20050315
>> >> >0033 : 31 36 33 33 33 30 5A 23 30 30 30 30 30 31 23 30
>> >163330Z#000001#0
>> >> >0043 : 30 23 30 30 30 30 30 30 __ __ __ __ __ __ __ __
>> >0#000000
>> >> >004B : }
>> >> >004B : }
>> >> >
>> >> >AND THIS which comes back if my client connects with an older cookie,
>> >> >followed by the response above.
>> >> >
>> >> >0000 146: SEQUENCE {
>> >> >0003 1: INTEGER = 2
>> >> >0006 140: [APPLICATION 25] {
>> >> >0009 24: [CONTEXT 10]
>> >> >000B : 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 34 32 30 33
>> >1.3.6.1.4.1.4203
>> >> >001B : 2E 31 2E 39 2E 31 2E 34 __ __ __ __ __ __ __
>> >__ .1.9.1.4
>> >> >0023 112: [CONTEXT 11]
>> >> >0025 : A3 6E 31 6C 04 10 40 59 47 D0 23 7A 10 29 91
>> >2A .n1l..@YG.#z.).*
>> >> >0035 : 90 61 61 9A 89 0B 04 10 D2 80 A8 BA 25 FA 10
>> >29 .aa.........%..)
>> >> >0045 : 8E 95 94 C1 3F CB 53 CE 04 10 9B 33 A5 F2 26
>> >C1 ....?.S....3..&.
>> >> >0055 : 10 29 9E 3A E7 B7 04 1D 82 48 04 10 F5 52 BF
>> >82 .).:.....H...R..
>> >> >0065 : 26 C1 10 29 9E 3B E7 B7 04 1D 82 48 04 10 5C 6D
>> >&..).;.....H..\m
>> >> >0075 : 13 D4 26 C2 10 29 9E 3C E7 B7 04 1D 82 48 04
>> >10 ..&..).<.....H..
>> >> >0085 : D4 BE C4 3E 26 C4 10 29 92 95 DC CB 4F 43 CF
>> >50 ...>&..)....OC.P
>> >> >0095 : }
>> >> >0095 : }
>> >> >
>> >> >The CONTEXT 11 field should just be the responseValue which by
>> >> >definition should be a SyncInfoValue but it won't parse that way.
>> >> >
>> >> >Could someone please provide some help with this. Honestly I'm
>> >> >confused and don't know exactly what to try next.
>> >> >
>> >> >Lee
>> >>
>>