Wireshark-dev: Re: [Wireshark-dev] capture_file* in dissector code
From: Evan Huus <eapache@xxxxxxxxx>
Date: Wed, 13 Nov 2013 12:17:17 -0500
On Wed, Nov 13, 2013 at 11:25 AM, <mmann78@xxxxxxxxxxxx> wrote: > I don't think the GUI should have any specific dissector knowledge unless > "absolutely necessary" (separating "business logic" from UI). I know that's > not how all the code is written now, but I think it's something to strive > for, especially with the switch to qt (and how I've interpreted some of > Gerald's comments about not just doing a "straight port" of some of the GTK+ > GUI functionality) Agreed, but things like the TCP stream graph inherently require specific dissector knowledge, so we'll never get rid of it entirely. > I think "decode as" as a concept should be generic enough to not have to > write specific GUI dialogs for each dissector that wants one, thus possibly > requiring "dissector knowledge" in the form of specific packet_info members > or "external" APIs from the dissector strictly for the GUI. Which sort of > puts it in a layer between dissection and GUI, so I thought that meant "epan > directory". > > Currently the Decode As feature has to ask "do I have a packet of type X to > do a decode as operation on?". One of the answers to that question is > "check pinfo->mpls_label" for MPLS packets. I think the MPLS dissector > should use p_get_proto_data() instead of pinfo->mpls_label in a "decode as > callback" to determine if a packet contains MPLS, rather than add > p_get_proto_data() to the Decode As GUI. I believe > p_get_proto_data/p_add_proto_data can be used to replace the mpls_label > member in the packet_info structure, but I don't like the idea of the GUI > calling it. 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? > -----Original Message----- > From: Evan Huus <eapache@xxxxxxxxx> > To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx> > Sent: Wed, Nov 13, 2013 10:46 am > Subject: Re: [Wireshark-dev] capture_file* in dissector code > > On Nov 13, 2013, at 9:41 AM, mmann78@xxxxxxxxxxxx wrote: > > The ulterior motive is actually to reduce members in the packet_info* > structure. Some members could be converted to using > p_get_proto_data/p_add_proto_data, but the "protocol ID" is required for > that API. While I've seen it hacked into a few places in the GUI, I think > it's better design if only a dissector has access to that value. > > > Why? I think a few dissectors already share that value for determining the > value of the parent protocol (since that is stored as a list of protocol IDs > now) and I don't see any particular reason to restrict protocol IDs to just > dissector code? > > The idea is to have the dissectors themselves determine what gets presented > in a "Decode As" by registering a "decode as structure". > > > I'm missing how this is related to removing items from pinfo. > > > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
- Follow-Ups:
- Re: [Wireshark-dev] capture_file* in dissector code
- From: mmann78
- Re: [Wireshark-dev] capture_file* in dissector code
- References:
- Re: [Wireshark-dev] capture_file* in dissector code
- From: mmann78
- Re: [Wireshark-dev] capture_file* in dissector code
- Prev by Date: Re: [Wireshark-dev] capture_file* in dissector code
- Next by Date: Re: [Wireshark-dev] capture_file* in dissector code
- Previous by thread: Re: [Wireshark-dev] capture_file* in dissector code
- Next by thread: Re: [Wireshark-dev] capture_file* in dissector code
- Index(es):
- Get Wireshark
- Download
- Code of Conduct