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

[Vincent Randal <vtrandal@xxxxxxxxx>]

Greetings everyone,

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? That could make sense if the ASN.1 was usable by ans2wrs(). In that case the dissector is then manually created? Or extra work goes into the .cnf (or other files) to get the dissector completed?

Background:

I'm here to specify a new protocol using ASN.1 (in some sense I represent a standards body in your previous description). Because I believe Wireshark has good support for ASN.1 based dissector development I am hoping to get a dissector from the ASN.1 description that I will be writing.

[Should the following question be a new separate question?]

2. How to add a new ASN.1 "foo" dissector to cmake [in ./epan/dissectors/asn1/CMakeLists]?

I want to start with a simple ASN.1 example so I chose the "foo" protocol dissector mentioned here:

https://www.wireshark.org/docs/wsdg_html_chunked/Asn1DissectorRequirements.html

I created the 4 source code files (in foo subdirectory) from the content provided here:

https://www.wireshark.org/docs/wsdg_html_chunked/SimpleASN1BasedDissector.html

Problem: I don't know what else to do to get it to build. I want my dissector to be built like those in ./epan/dissectors/asn1 (i.e. not a plugin).

I've tried adding "foo" in the list of directories in the parent CMakeLists.txt (but that does not affect build).

By the way: The first thing I did was build wireshark-3.4.4 from source using cmake and that works.

Vincent Randal

On Sat, Apr 10, 2021 at 9:50 PM John Thacker <johnthacker@xxxxxxxxx> wrote:

On Sat, Apr 10, 2021 at 11:15 PM Vincent Randal <vtrandal@xxxxxxxxx> wrote:

Greetings,  everyone. I’ve a question regarding:

https://www.wireshark.org/docs/wsdg_html_chunked/Asn1DissectorRequirements.html

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

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe