No, Decode As is currently quite limited (hardcoded) in what you can change dissection to. But I'm guessing ethernet, IP, TCP/UDP (which are all supported) cover a large majority of users.
There can be multiple factors to consider and that's why (I'm guessing) it's as complex as it is (Haven't looked at the gory details behind the engine). For ethernet and IP, yes just child dissectors would do. But for TCP/UDP you have the option to decode in one or both directions of the "stream". I assume the other protocol (as well as "taps") setups have "options" as well. Currently my goal is to just make the existing protocols supported through Decode As work in a more generic way to reduce GUI footprint, but I think you're right that just checking for registered child dissectors would be the ultimate goal. Still curious as to the opinion of being allowed to use capture_file* in dissectors. -----Original Message----- From: Evan Huus <[email protected]> To: Developer support list for Wireshark <[email protected]> Sent: Wed, Nov 13, 2013 12:19 pm Subject: Re: [Wireshark-dev] capture_file* in dissector code I wasn't aware that Decode As was this complicated at all - I thought it simply referenced the various dissector table registrations to generate the relevant lists? Should it not simply be checking if there are registered child dissectors?
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
