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
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
