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.]