Typo: I wrote usable when I meant unusable in this sentence: "the ASN.1 was usable by ans2wrs()"
On Mon, Apr 12, 2021 at 11:08 PM Vincent Randal <vtran...@gmail.com> wrote: > 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 <johnthac...@gmail.com> > wrote: > >> On Sat, Apr 10, 2021 at 11:15 PM Vincent Randal <vtran...@gmail.com> >> 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@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe > >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
