[Anders Broman <anders.broman@xxxxxxxxxxxx>]

Hi,

I think you should go for 2. Wouldn’t this type of construct from the goose protocol work?

 

GSEMngtRequests ::= CHOICE {

                           getGoReference                        [1] IMPLICIT GetReferenceRequestPdu,

                           getGOOSEElementNumber     [2] IMPLICIT GetElementRequestPdu,

                           getGsReference                         [3] IMPLICIT GetReferenceRequestPdu,

                           getGSSEDataOffset                   [4] IMPLICIT GetElementRequestPdu,

                           ...

}

e.g.

MyNewProtocolMessages ::= CHOICE{

   myMeasge1 [1] IMPLICIT MyMessage1,

   :

Repeated as many times as needed, MyMessage1 could have sub messages or whatever…

I assume the encoder will be using an ASN1 encoder to serialize the data.

Regards

Anders

 

From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf Of Vincent Randal
Sent: den 22 juni 2021 08:55
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: [Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

 

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature