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
