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.