ASN.1-based dissector decoding by port number vs switch/case using 1st octet

[Vincent Randal <vtrandal () gmail com>]

Hello everyone in the Wireshare-dev community,

The primary question in this email (but I think it requires some
explanation below): How does one write an ASN.1-based dissector such that
the generated code (per "make asn1") does indeed decode the first octet as
the message type using C-style switch/case construct?

In May I sat in (online) at an online Wireshark Developer Den meeting. I
asked about encoding schemes like that in IEEE 1451.0 where the first octet
is used to decode the message. I got a response indicating it was natural
to use a switch/case statement in C programming to decode the messages (all
of them, with one switch/case statement). [I gather that one switch/case
statement for decoding all messages of a protocol implies one enumeration
table for encoding them in the first octet.]

But I did not understand that until today. Nor did I know how to modify the
ASN.1-based dissector “foo” to make it work with a switch/case statement.
It had build errors from the change to cmake; I renamed it “myfoo” in my
repository and fixed the build errors (I have been slow to make a MR, merge
request, for it). I made the decision to base decoding entirely on port
number and make one dissector per message per port number. Yuck, but that’s
what I did. The current approach would add over 100 new folders to asn1
folder in (./epan/dissectors/asn1).  Is that acceptable? To add over 100
new folders in asn1 for a new protocol? [I am helping design a new
protocol].

I am consider two options:

1. Explore the possibility of using a port-range since tcpdump and tshark
support portrange filtering. To me that implies the possibility that people
could indeed be implementing protocols with one dissector per message per
port (and conceivably are using a lot ports for a single protocol in some
cases). This new protocol allows for hundreds of unique messages. It seems,
however, a port range of several hundred ports for one protocol is
impractical and wasteful of port numbers. But ignoring that objection for
the moment I press on, and ask how I might I put several hundred dissectors
into a single source-tree under the asn1 folder (in
./epan/dissectors/asn1)? Again, assuming it's okay to use up several
hundred UDP ports for a single protocol: What success might have during
build step "make asn1" that it will generate dissectors from a source-tree
of dissectors in one folder in the asn1 folder? For example, I am thinking
I will put a group of dissectors in ./asn1/netsvc/ and another group in
./asn1/xdrsvc, and so on. Is anyone doing this? Is this supported in the
current build process?

2. Give up on #1 above, and do something sane like use the first octet to
encode the message type rather than waste hundreds of ports on a
single-port-per-message-per-dissector approach describe in #1 above. This
brings me back to the response I got in the Wireshark Developer Den in May:
Use a C switch/case statement to decode the messages. Okay, I want to that
do that. But I don't know how to do that for ASN.1-based dissectors. If I
can learn how to do that then I would revise the "foo" dissector (simple
ASN.1-based dissector) to be exactly that, get it working, and make my MR
(merge-request for that and final give something back to this community
that has been so helpful to me).

I like option #2 above, because it uses a single UDP for the entire
protocol (again, this is a new protocol being developed as an IEEE
standard). We could still end up using a few ports perhaps (one port per
group of messages). For example, IEEE 1451.0 Network Services would get one
UDP port, IEEE 1451.0 Transducer Services would get another port, and so
on. Then the protocol would need only a handful of port numbers at the
most. Either way the issue remains: How does one even begin to write an
ASN.1-based dissector such that the generated code (per "make asn1") does
indeed decode the first octet as the message type using C-style switch/case
construct? Is there an example that I can look at?

Thanks for reading to the end of my long and winding request for help.

Sincerely,
Vincent Randal
Longmont, Colorado

___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe