On Apr 12, 2021, at 10:08 PM, Vincent Randal <vtrandal@xxxxxxxxx> wrote:
> Thank you (John) for delving into a nice description of the overall process. I do have a couple more questions for you and the group:
> 1. What is the meaning of "work is in progress to at least read all ASN1 specifications" ???
> I'm trying to imagine what that implies. Does it imply some dissectors in ./epan/dissectors/asn1 have an .asn file that is not being read?
No.
It implies that not all of the specifications out there that are in the form of text files using ASN.1's descriptive syntax can be handled by asn2wrs, so there are some specifications that would need manual tweaking to work with asn2wrs.
That may be the case for some of the epan/dissectors/asn1/*/*.asn files.
I don't know what all the limitations are, or whether anybody's *currently* working on removing any such limitations. I don't think there's much being done to the specification for the ASN.1 descriptive syntax, so I don't think there's much that would be getting more out of date; it's more a question of some features in the X.whatever specs that isn't supported.
The .cnf file's main purpose is to add additional semantics for fields that affects the way Wireshark dissects and displays them, over and above what can be expressed in the ASN.1 specification language. For example, a field might be specified, in the specification language, as an OCTET STRING, but it might contain a blob of data with substructure *not* using the encoding rule for the protocol and thus *not* specifiable in the specification.
And, even if it *could* be specified using ASN.1 specification syntax, doing so would mean modifying the .asn file, and if the specification is updated, and we wanted to update the .asn file to the latest version, we'd have to merge the specification changes and our changes. That's what "Changing the ASN1 file is being depreciated as this creates problems when updating protocols." means.
