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

[Vincent Randal <vtrandal () gmail com>]

On Sat, Jun 26, 2021 at 9:41 PM Guy Harris <gharris () sonic net> wrote:

> So this isn't really a Wireshark dissector question, it's a protocol
> design and encoding question.
I'd like it not to be an encoding question beyond this: Given I'm using
ASN.1 to generate dissectors (for the protocols I am designing), which
encoding can I use so that I can "see" my messages in the raw data?

> The issue isn't "how do I get a Wireshark dissector to distinguish between
> different message types without giving each message type its own UDP port",
> it's "how do I get *the recipient of the messages* to distinguish between
> different message types without giving each message type its own UDP port"
> - this would be an issue even if there were no such thing as packet
> analyzers, because you'd be wasting the ports even if there were no packet
> analyzers.
At this stage Wireshark is the only recipient of these messages that I care
about. I send the messages using Python asn1tools and receive them using
tshark (perhaps also using Lua soon). Guy, you and Graham helped there.
Thank you.

> And it's best thought of not as a question of "using the first octet" as a
> question of "somehow encoding the message type in the message itself" -
> with Anders' suggestion of a change to the protocol, in BER, the first
> octet would contain information other than just the ClassNumber for the
> item in the CHOICE, and in PER, with the UNALIGNED variant, the ClassNumber
> would be encoded in the minimum number of bits needed to encode the range
> of ClassNumbers.
I am using PER (apparently the ALIGNED variant) because (so far) I can
"see" the messages in the raw hexadecimal dump. I want a “null” encoder
with this property: pre-encoded message byte = encoded message octet.

> (And if there are over 100 different message types, depending on the
> encoding, it might not even fit in one octet, at least for BER.)
>
> The good news is that, if you generate the protocol implementation from
> the ASN.1, that will all be done for you - you won't have to write

I’m not finding freely available tools that finish the job. I’m writing my
own tools to fill in the gaps. My tools generate ASN.1 from IEEE source
documents (which they update after testing).

> the code to parse the encoding of the value, esnacc (which translates from
> the IDL, ASN.1, *to* code, it doesn't translate ASN.1 to an IDL) will do
> that for you.  The same is true of Wireshark's

Guy, look at "esnacc -idl" [I merge the output of "esnacc" and "esnacc
-idl" to create an IDL that passes "omniidl" syntax checking. I give a
variant of this IDL to the IEEE for use as their message descriptions.]

> dissector generation; in neither case would *you* need to write a switch
> statement, or whatever would be involved.
> ___________________________________________________________________________
> 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
___________________________________________________________________________
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