Re: slapo-dds and data decoding error
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.