Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Fwd: ASN.1 dissector Wireshark

From: John Thacker <johnthacker@xxxxxxxxx>
Date: Sat, 10 Apr 2021 23:49:24 -0400
On Sat, Apr 10, 2021 at 11:15 PM Vincent Randal <vtrandal@xxxxxxxxx> wrote:
Greetings,  everyone. I’ve a question regarding:

I take this to mean Wireshark ASN.1 support might not be up to date going forward. Is that the meaning? ASN.1 has a long history. It makes sense periodically to freeze support for specific versions of ASN.1. Is that the meaning here (Changing the ASN1 file is being depreciated)? It says:

The compiler needs 4 input files: an ASN.1 description of a protocol, a .cnf file, and two template files. The ASN.1 specification may have to be edited to work, however work is in progress to at least read all ASN1 specifications. Changing the ASN1 file is being depreciated as this creates problems when updating protocols. The H.248 Binary encoding dissector is a good example of a dissector with relatively small changes.


No, I take that to mean:

Many protocols (especially those associated with the ITU-T or ETSI) are formally specified in ASN.1. Sometimes it is difficult for asn2wrs.py, the ASN.1 to Wireshark dissector compiler, to translate the ASN.1 specification into code that works optimally (and in rare cases, even at all) as a Wireshark dissector. (Fairly trivial examples include protocols that define certain fields as OCTET STRINGs of length 1, 2, 3, or 4, when in Wireshark they would be better displayed as uint{8,16,24,32}, but much more complicated examples exist.)

In such cases, the preferred method is to edit the .cnf file or the template files (packet-PROTOABBREV-template.[ch]), rather than edit the ASN.1 description directly, as the latter comes from the official protocol specification as defined by the standards body. While the ultimate goal is for asn2wrs.py to at least successfully read all ASN.1 specifications and produce usable output (even if the .cnf file or template files must be adjusted), in rare cases it may fail to do so, and then it will be necessary to edit the ASN.1 file itself. However, editing the file is deprecated and should be viewed as a last resort, as any such changes would have to be reapplied when the protocol is updated to a later released version of the specification with a new official ASN.1 definition. Problems sometimes result, as occurs anytime forked code has to be merged.

John Thacker