I've ran across a bunch of dissectors lately that don't have an IANA registered port, so they add a port preference. This is done is one of two ways: 1. Assigning their "randomly picked" port number to the preference, possibly requiring a user to change (set to 0) if it interferes with their traffic. Since these are usually niche protocols, I can understand someone being annoyed by the "interference". 2. Defaulting port preference to 0, then making sure it's non-zero when registering with the (TCP/UDP) dissector table. If not careful, sometimes the dissector isn't registered at all, so Decode As can't be used.
Since Decode As can also be persistent, wouldn't that be a better way to (force users to) go? To me it has similar logic/justification as when I removed the "subdissector preferences" in favor of Decode As. While it would be nice to have users go to a single place to decide a "heuristic hierarchy" (a subject that is touched on from time to time), having port preferences seems to spread it out more than necessary. I'm hesitant because of the number of backwards compatibility issues it could introduce, but if we converted the preferences into the Decode As structure (if found), wouldn't that alleviate a lot of it? I'm more okay with keeping "range" preferences for protocols (at least for now) as that seems a more tedious task to do with Decode As.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
