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

[<herbfalkmi () gmail com>]

I have a GOOSE dissector already written, but it is not a compiled version.  Due to using old wireshark ASN.1 decoder 
code, and other reasons, it has not been integrated into the main code. The install at 
http://www.otb-consultingservices.com/brainpower/shop/ even includes an SCL parser that allows the dissector to show 
the names of the DataSet members.

 

 

 

From: Wireshark-dev <wireshark-dev-bounces () wireshark org> On Behalf Of Anders Broman via Wireshark-dev
Sent: Tuesday, June 22, 2021 6:59 AM
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Cc: Anders Broman <anders.broman () ericsson com>
Subject: Re: [Wireshark-dev] ASN.1-based dissector decoding by port number vs switch/case using 1st octet

 

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 () wireshark org <mailto:wireshark-dev-bounces () wireshark org> > On Behalf 
Of Vincent Randal
Sent: den 22 juni 2021 08:55
To: Developer support list for Wireshark <wireshark-dev () wireshark org <mailto: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

___________________________________________________________________________
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