I'm trying to create a LDAP bind request as described in https://datatracker.ietf.org/doc/html/rfc4511#section-4.2, using the asn1 API in Fantom. Clients I've seen elsewhere seem to apply the "Context" tag directly to a string without any other tags (e.g. "univOcts" etc), and I don't see a way to do that with the existing AsnObjBuilder API.

Other clients: https://github.com/zont/ldapjs-client/blob/master/src/requests/bind_request.js https://github.com/go-ldap/ldap/blob/master/v3/bind.go#L49-L61

Not exactly sure which component of the Bind you are trying to create, but you can make a utf8 string with CONTEXT 1 doing this:

Asn.utf8("username").push(AsnTag.context(1).implicit)

I might recommend using Java native APIs directly for doing an LDAP client though.

using [java]java.util
using [java]javax.naming
using [java]javax.naming::Context as JndiContext
using [java]javax.naming::NamingException
using [java]javax.naming.directory
using [java]javax.naming.directory::SearchResult as JSearchResult
using [java]fanx.interop

Thanks! I think the implicit tags were the trick to getting that bind request to work. Meanwhile I'm also seeing behavior where the responses keep getting read in as the @NoDoc AsnBin objects.

Below is what a SearchResultEntry looks like when running BerReader(socket.in).readObj():

[<univ, 16, explicit>] {
  [<univ, 2, explicit>] 4
  [<app, 4, implicit>, <univ, -1, explicit>] Unsafe(MemBuf(pos=0 size=259))
}

I can do something where I make another BerReader to read the buf.in coming from that MemBuf, but the deeper objects just do something similar with aanother structure encapsulating an Unsafe(MemBuf(...)). Is there a suggestion you'd have for this, other than just trying to read any object I see that has this <univ, -1> tag, and swap in the result?

I tested some changes in the source for the asn1 pod, and it's ultimately in BerReader.doReadObj(); reading the tag finds and classifies the application tag rather than a universal one and the code for tryUniversal() returns null so it falls back to AsnBin. I've found that if I put code that notices that the first tag mode is implicit and it just reads tags until it finds a universal one, I can get a more accurate structure. The next that I run into is that octet strings still get kept as Buffers instead of being interpreted as string values. I think fortunately for my use case, a non-zero search result count is probably enough information.

FWIW, Here's the buffer I've been testing with.

Int[] searchResult := [
    0x30, 0x81, 0xb9, 0x02, 0x01, 0x02, 0x64, 0x81 , 0xb3, 0x04, 0x26, 0x63, 0x6e, 0x3d, 0x72, 0x65,
    0x61, 0x64, 0x65, 0x72, 0x73, 0x2c, 0x6f, 0x75 , 0x3d, 0x67, 0x72, 0x6f, 0x75, 0x70, 0x73, 0x2c,
    0x64, 0x63, 0x3d, 0x65, 0x78, 0x61, 0x6d, 0x70 , 0x6c, 0x65, 0x2c, 0x64, 0x63, 0x3d, 0x6f, 0x72,
    0x67, 0x30, 0x81, 0x88, 0x30, 0x0f, 0x04, 0x02 , 0x63, 0x6e, 0x31, 0x09, 0x04, 0x07, 0x72, 0x65,
    0x61, 0x64, 0x65, 0x72, 0x73, 0x30, 0x1d, 0x04 , 0x0b, 0x6f, 0x62, 0x6a, 0x65, 0x63, 0x74, 0x43,
    0x6c, 0x61, 0x73, 0x73, 0x31, 0x0e, 0x04, 0x0c , 0x67, 0x72, 0x6f, 0x75, 0x70, 0x4f, 0x66, 0x4e,
    0x61, 0x6d, 0x65, 0x73, 0x30, 0x56, 0x04, 0x06 , 0x6d, 0x65, 0x6d, 0x62, 0x65, 0x72, 0x31, 0x4c,
    0x04, 0x24, 0x63, 0x6e, 0x3d, 0x75, 0x73, 0x65 , 0x72, 0x30, 0x31, 0x2c, 0x6f, 0x75, 0x3d, 0x75,
    0x73, 0x65, 0x72, 0x73, 0x2c, 0x64, 0x63, 0x3d , 0x65, 0x78, 0x61, 0x6d, 0x70, 0x6c, 0x65, 0x2c,
    0x64, 0x63, 0x3d, 0x6f, 0x72, 0x67, 0x04, 0x24 , 0x63, 0x6e, 0x3d, 0x75, 0x73, 0x65, 0x72, 0x30,
    0x32, 0x2c, 0x6f, 0x75, 0x3d, 0x75, 0x73, 0x65 , 0x72, 0x73, 0x2c, 0x64, 0x63, 0x3d, 0x65, 0x78,
    0x61, 0x6d, 0x70, 0x6c, 0x65, 0x2c, 0x64, 0x63 , 0x3d, 0x6f, 0x72, 0x67
]
Buf getSearchResult() {
    Buf result := Buf.make(searchResult.size)
    searchResult.each |Int i| { result.write(i) }
    return result
}

I think the BER reader is probably working correctly. One of the challenges of working with ASN.1 encoded data is that without a description of the object (i.e. a MIB file) once we find a non-universal tag we don't know how to decode it. So typically it becomes an application-specific problem to take the raw AsnBin and use AsnBin.decode(spec) to decode it.

In the SearchResultEntry the univ type for that app tag is <unv, -1, explicit> which is the ASN ANY type. So that buf could be any encoded ASN value. Presumably there is other information in that structure to tell you how to decode that buf; maybe the <univ, 2, explict> 4 is some code that tells you how how to decode the rest of the message. That is pretty typical in ASN encoded data.

The BER Reader just calls it an ANY type because the tryUniversal kicked back a null.

In any case knowing that the app tag is where it stops short, I'll try doing something on the app-side to anticipate that and maybe do some kind of transformations; one for the case of the <univ, -1, explicit> and another to change those octet strings to something more useful for me.

Also - i still think you would get farther faster by using Java Native APIs for doing LDAP. That's basically what we did in our commercial LdapClient; instead of trying to write a full Fantom implementation of the LDAP spec.