Re: capture_file* in dissector code

[mmann78 () netscape net]

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 <eapache () gmail com>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
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 <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe