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

[David Ameiss <netshark@xxxxxxxxxxxxx>]

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