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
netsh...@ameissnet.com
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
