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-boun...@wireshark.org> On Behalf Of Vincent
Randal
Sent: den 22 juni 2021 08:55
To: Developer support list for Wireshark <wireshark-dev@wireshark.org>
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
smime.p7s
Description: S/MIME cryptographic signature
___________________________________________________________________________ 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
