So this isn't really a Wireshark dissector question, it's a protocol design and encoding question.
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. 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. (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 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 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-requ...@wireshark.org?subject=unsubscribe
