Wireshark · Wireshark-dev: Re: [Wireshark-dev] GUI functionality from plugins

[David Ameiss <netshark@xxxxxxxxxxxxx>]

And we currently use it (as noted below) to add menu items. For us, the 
critical item is cfile, to allow re-tapping captures.

I suppose the email subject was misleading. Yes, more GUI functionality 
would be wonderful. But cfile is really the issue for us (at least for now).

On 09/19/2012 02:11 PM, Luis EG Ontanon wrote:
> Actually, funnel.h implements some GUI functionality that can be used
> by plugins.
>
> More functionality can be added to it.
>
> On Wed, Sep 19, 2012 at 9:34 AM, David Ameiss<netshark@xxxxxxxxxxxxx>  wrote:
> > Summary: I'd like to propose implementing a method of making GUI
> > functionality more accessible from plugins.
> >
> > We have developed plugin dissectors for our internal protocols, all of which
> > are built on top of UDP and TCP. In addition, we've developed several
> > analytical tools within the plugin. One in particular is modeled after the
> > TCP flowgraph, and actually uses the graph_analysis.c functions to show
> > flows at the sub-frame level.
> >
> > A little explanation: We have a class of messages that allow one process to
> > unicast a message to another process. These are TCP, but are not treated as
> > bidirectional (for a number of reasons which aren't important here). So a
> > conversation between two such processes (actually, objects within a process,
> > identified by IP, port, and domain, which is a designator used for
> > forwarding) really involves a TCP connection from A to B, then another from
> > B to A. Each such message contains information about the destination
> > (domain, IP, and port), as well as where it is coming from (domain, IP, and
> > port).
> >
> > In a LAN, everyone is in the same domain, so things are easy. However, much
> > of our communication takes place across a WAN, between domains, and gateway
> > processes are used to bridge these domains. So while the ultimate
> > destination of a message is a specific domain, IP, and port, the message may
> > actually be sent to a gateway at a different domain, IP, and port. Hence the
> > destination and source embedded in the message.
> >
> > To complicate matters, multiple processes in one domain may be sending
> > messages to multiple processes in other domains, all sent via the
> > intervening gateway, and possibly multiple intervening gateways, depending
> > on where the destination domain actually is. So messages are multiplexed
> > together between gateways.
> >
> > This is not really ground-breaking, I know.
> >
> > What we have done is implement a flow-graph that identifies individual
> > "conversations" (not really the right word in terms of wireshark), and
> > follows them as they traverse possibly multiple gateway nodes. This is
> > incredibly useful, as you might imagine.
> >
> > This has been implemented following the TCP flowgraph model, which involves
> > a tap listener (the part of the dissector actually doing the dissection
> > queues tap packets - actually, since the protocol allows multiple messages
> > per frame, it can queue multiple tap entries per frame.
> >
> > The fundamental problem is that, in order to retap the capture, the plugin
> > needs access to cfile, which is defined in the Wireshark executable. This
> > works on Linux and OSX - but not on Windows, because cfile isn't exported.
> > And I think there are some issues with making symbols from an executable
> > exported for use by Windows DLLs - probably a solvable problem, but also
> > probably not easily.
> >
> > Yes, I know the best approach is to put our dissectors in the Wireshark
> > distribution, change from a plugin to a built-in, etc. I've been pushing
> > that for nearly 2 years. But that's a political issue, and it appears that
> > the path of least resistance is not to make a decision. So we're stuck with
> > that for now.
> >
> > One idea that occurred to me is the possibility of passing to a dissector a
> > parameter which gives (controlled) access to some things inside
> > wireshark/tshark. Possibly as a parameter to proto_register_XXX() or
> > proto_reg_handoff_XXX(). My thinking is along the lines of a structure which
> > contains either pointers to variables or callbacks which allow the variables
> > to be accessed. At minimum, for our purposes, a way to get at cfile is
> > needed. I'm sure others will have ideas for additional items. And down the
> > road, as Wireshark moves to a more generic GUI interface (as it seems to be
> > doing), this could give access to the various GUI components (such as adding
> > menu entries, although this can be done now via funnel_register_menu()).
> >
> > I realize the dissector/GUI split is useful, but I also know it is not in
> > concrete (the asn1 plugin, for example, creates windows). Short of
> > integrating our (admittedly application-specific) dissectors into Wireshark
> > itself, which isn't currently an option, the only way to provide the
> > analytical functionality is via GUI in the plugin.
> >
> > I would appreciate any comments.
> >
> >
> > --
> > David Ameiss
> > netshark@xxxxxxxxxxxxx
> > ___________________________________________________________________________
> > 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


--
David Ameiss
netshark@xxxxxxxxxxxxx