Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

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

From: David Ameiss <netshark@xxxxxxxxxxxxx>
Date: Wed, 19 Sep 2012 09:34:47 -0500
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