Re: slapo-dds and data decoding error

[Michael Ströder <michael@stroeder.com>]

Jochen,

thanks for your answer.

Keutel, Jochen (mlists) wrote:
>   look at this request:
> 
>> ber_dump: buf=0x7fae6d002260 ptr=0x7fae6d002260 end=0x7fae6d0022b9 len=89
>>    0000:  02 01 02 77 54 80 1a 31  2e 33 2e 36 2e 31 2e 34  
>> ...wT..1.3.6.1.4
>>    0010:  2e 31 2e 31 34 36 36 2e  31 30 31 2e 31 31 39 2e  
>> .1.1466.101.119.
>>    0020:  31 81 36 30 34 04 2d 63  6e 3d 44 44 53 20 54 65  
>> 1.604.-cn=DDS Te
>>    0030:  73 74 20 52 61 75 6d 2c  6f 75 3d 54 65 73 74 69   st
>> Raum,ou=Testi
>>    0040:  6e 67 2c 64 63 3d 73 74  72 6f 65 64 65 72 2c 64  
>> ng,dc=stroeder,d
>>    0050:  63 3d 64 65 02 03 01 51  80                        c=de...Q.
> 
> I think between the OID 1.3.6.1.4.1.1466.101.119.1 and the request value
> there are two bytes more than needed:
> 
> 81 36
> 
> This is probably the tag [1] and the length field.
> 
> I think this has to be omitted because tagging in LDAP is implicit. So
> tags like [1] before an octet string have to be omitted.

Ok, now the request works as expected.

But the response sends back  tag [0] instead of [1] as described in section
4.2 of RFC 2589:

   The response field will contain as a value the DER-encoding of the
   following ASN.1 data type:

        SEQUENCE {
                responseTtl [1] INTEGER
        }

If I use [0] wehn decoding it works...

Ciao, Michael.