forked from osmocom/wireshark
![Roland Knall](/assets/img/avatar_default.png)
Rename ext_menubar to a more appropriate plugin_if. External menus can be implemented by plugins to present additional menus for deep-packet analysis. One side-effect of such menus being implemented as plugins is, that they are being executed in different threads and therefore can only use limited access to the main GUI. Also, there is no safe cross-gui (GTK and Qt) way for many features. This patch implements a first functionality, by which a plugin implemented using ext_menubar can apply a display filter to the main view. For now the implementation supports filtering, as well as saving a preference. Change-Id: Iffe4caa954bbeb8ce356352de4dae348a50efba9 Reviewed-on: https://code.wireshark.org/review/8773 Reviewed-by: Roland Knall <rknall@gmail.com> Petri-Dish: Anders Broman <a.broman58@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
404 lines
12 KiB
Text
404 lines
12 KiB
Text
1. Plugins
|
|
|
|
Writing a "plugin" dissector is not very different from writing a standard
|
|
one. In fact all of the functions described in README.dissector can be
|
|
used in the plugins exactly as they are used in standard dissectors.
|
|
|
|
(Note, however, that not all OSes on which Wireshark runs can support
|
|
plugins.)
|
|
|
|
If you've chosen "foo" as the name of your plugin (typically, that would
|
|
be a short name for your protocol, in all lower case), the following
|
|
instructions tell you how to implement it as a plugin. All occurrences
|
|
of "foo" below should be replaced by the name of your plugin.
|
|
|
|
2. The directory for the plugin, and its files
|
|
|
|
The plugin should be placed in a new plugins/foo directory which should
|
|
contain at least the following files:
|
|
|
|
AUTHORS
|
|
COPYING
|
|
ChangeLog
|
|
CMakeLists.txt
|
|
Makefile.am
|
|
Makefile.common
|
|
Makefile.nmake
|
|
moduleinfo.h
|
|
moduleinfo.nmake
|
|
plugin.rc.in
|
|
And of course the source and header files for your dissector.
|
|
|
|
Examples of these files can be found in plugins/gryphon.
|
|
|
|
2.1 AUTHORS, COPYING, and ChangeLog
|
|
|
|
The AUTHORS, COPYING, and ChangeLog are the standard sort of GPL project
|
|
files.
|
|
|
|
2.2 CMakeLists.txt
|
|
|
|
For your plugins/foo/CMakeLists.txt file, see the corresponding file in
|
|
plugins/gryphon. Replace all occurrences of "gryphon" in those files
|
|
with "foo" and add your source files to the DISSECTOR_SRC variable.
|
|
|
|
2.3 Makefile.am
|
|
|
|
For your plugins/foo/Makefile.am file, see the corresponding file in
|
|
plugins/gryphon. Replace all occurrences of "gryphon" in those files
|
|
with "foo".
|
|
|
|
2.4 Makefile.common
|
|
|
|
Your plugins/foo/Makefile.common should only list the main source file(s),
|
|
which exports register_*() and handoff_*(), for your dissector in the
|
|
DISSECTOR_SRC variable. All other supporting source files should be
|
|
listed in the DISSECTOR_SUPPORT_SRC variable.
|
|
The header files for your dissector, if any, must be listed in the
|
|
DISSECTOR_INCLUDES variable. The DISSECTOR_INCLUDES variable should not
|
|
include moduleinfo.h.
|
|
|
|
2.5 Makefile.nmake
|
|
|
|
For your plugins/foo/Makefile.nmake file, see the corresponding file in
|
|
plugins/gryphon. No modifications are needed here.
|
|
|
|
2.6 moduleinfo.h
|
|
|
|
Your plugins/foo/moduleinfo.h file is used to set the version information
|
|
for the plugin.
|
|
|
|
2.7 moduleinfo.nmake
|
|
|
|
Your plugins/foo/moduleinfo.nmake is used to set the version information
|
|
for building the plugin. Its contents should match that in moduleinfo.h
|
|
|
|
2.8 plugin.rc.in
|
|
|
|
Your plugins/foo/plugin.rc.in is the Windows resource template file used
|
|
to add the plugin specific information as resources to the DLL.
|
|
No modifications are needed here.
|
|
|
|
3. Changes to existing Wireshark files
|
|
|
|
There are two ways to add your plugin dissector to the build, as a custom
|
|
extension or as a permanent addition. The custom extension is easy to
|
|
configure, but won't be used for inclusion in the distribution if that's
|
|
your goal. Setting up the permanent addition is somewhat more involved.
|
|
|
|
3.1 Custom extension
|
|
|
|
Go to the plugins directory and copy the three Custom.*.example files to
|
|
Custom.*. Now you have three files ready for building a plugin with the
|
|
name "foo". Replace the name if you so require.
|
|
|
|
If you want to add the plugin to your own Windows installer add a text
|
|
file named custom_plugins.txt to the packaging/nsis directory, with a
|
|
"File" statement for NSIS:
|
|
|
|
File "..\..\plugins\foo\foo.dll"
|
|
|
|
Then open packaging/nsis/Custom.nmake and add the relative path to your
|
|
DLL to CUSTOM_PLUGINS:
|
|
|
|
CUSTOM_PLUGINS= \
|
|
../../plugins/foo/foo.dll
|
|
|
|
3.2 Permanent addition
|
|
|
|
In order to be able to permanently add a plugin take the following steps.
|
|
You will need to change the following files:
|
|
configure.ac
|
|
CMakeLists.txt
|
|
epan/Makefile.am
|
|
Makefile.am
|
|
packaging/nsis/Makefile.nmake
|
|
packaging/nsis/wireshark.nsi
|
|
plugins/Makefile.am
|
|
plugins/Makefile.nmake
|
|
|
|
You might also want to search your Wireshark development directory for
|
|
occurrences of an existing plugin name, in case this document is out of
|
|
date with the current directory structure. For example,
|
|
|
|
grep -rl gryphon .
|
|
|
|
could be used from a shell prompt.
|
|
|
|
3.2.1 Changes to plugins/Makefile.am
|
|
|
|
The plugins directory contains a Makefile.am. You need to add to SUBDIRS
|
|
(in alphabetical order) the name of your plugin:
|
|
|
|
SUBDIRS = $(_CUSTOM_SUBDIRS_) \
|
|
...
|
|
ethercat \
|
|
foo \
|
|
gryphon \
|
|
irda \
|
|
|
|
|
|
3.2.2 Changes to plugins/Makefile.nmake
|
|
|
|
In plugins/Makefile.nmake you need to add to PLUGINS_LIST (in alphabetical
|
|
order) the name of your plugin:
|
|
|
|
PLUGIN_LIST = \
|
|
...
|
|
ethercat \
|
|
foo \
|
|
gryphon \
|
|
irda \
|
|
|
|
3.2.3 Changes to the top level Makefile.am
|
|
|
|
Add your plugin (in alphabetical order) to plugin_ldadd:
|
|
|
|
if HAVE_PLUGINS
|
|
|
|
plugin_ldadd = $(_CUSTOM_plugin_ldadd_) \
|
|
...
|
|
-dlopen plugins/ethercat/ethercat.la \
|
|
-dlopen plugins/foo/foo.la \
|
|
-dlopen plugins/gryphon/gryphon.la \
|
|
-dlopen plugins/irda/irda.la \
|
|
...
|
|
|
|
3.2.4 Changes to the top level configure.ac
|
|
|
|
You need to add your plugins Makefile (in alphbetical order) to the
|
|
AC_OUTPUT rule in the configure.ac
|
|
|
|
AC_OUTPUT(
|
|
...
|
|
plugins/ethercat/Makefile
|
|
plugins/foo/Makefile
|
|
plugins/gryphon/Makefile
|
|
plugins/irda/Makefile
|
|
...
|
|
,)
|
|
|
|
3.2.5 Changes to epan/Makefile.am
|
|
|
|
Add the relative path of all your plugin source files (in alphbetical
|
|
order) to plugin_src:
|
|
|
|
plugin_src = \
|
|
...
|
|
../plugins/ethercat/packet-ioraw.c \
|
|
../plugins/ethercat/packet-nv.c \
|
|
../plugins/foo/packet-foo.c \
|
|
../plugins/gryphon/packet-gryphon.c \
|
|
../plugins/irda/packet-ircomm.c \
|
|
../plugins/irda/packet-irda.c \
|
|
...
|
|
|
|
3.2.6 Changes to CMakeLists.txt
|
|
|
|
Add your plugin (in alphabetical order) to the PLUGIN_SRC_DIRS:
|
|
|
|
if(ENABLE_PLUGINS)
|
|
...
|
|
set(PLUGIN_SRC_DIRS
|
|
...
|
|
plugins/ethercat
|
|
plugins/foo
|
|
plugins/gryphon
|
|
plugins/irda
|
|
...
|
|
|
|
3.2.7 Changes to the installers
|
|
|
|
If you want to include your plugin in an installer you have to add lines
|
|
in the NSIS installer Makefile.nmake and wireshark.nsi files.
|
|
|
|
3.2.7.1 Changes to packaging/nsis/Makefile.nmake
|
|
|
|
Add the relative path of your plugin DLL (in alphbetical order) to PLUGINS:
|
|
|
|
PLUGINS= \
|
|
...
|
|
../../plugins/ethercat/ethercat.dll \
|
|
../../plugins/foo/foo.dll \
|
|
../../plugins/gryphon/gryphon.dll \
|
|
../../plugins/irda/irda.dll \
|
|
|
|
3.2.7.2 Changes to packaging/nsis/wireshark.nsi
|
|
|
|
Add the relative path of your plugin DLL (in alphbetical order) to the
|
|
list of "File" statements in the "Dissector Plugins" section:
|
|
|
|
File "${STAGING_DIR}\plugins\${VERSION}\ethercat.dll"
|
|
File "${STAGING_DIR}\plugins\${VERSION}\foo.dll"
|
|
File "${STAGING_DIR}\plugins\${VERSION}\gryphon.dll"
|
|
File "${STAGING_DIR}\plugins\${VERSION}\irda.dll"
|
|
|
|
3.2.7.3 Other installers
|
|
|
|
The PortableApps installer copies plugins from the build directory
|
|
and should not require configuration.
|
|
|
|
4. Development and plugins on Unix
|
|
|
|
Plugins make some aspects of development easier and some harder.
|
|
|
|
The first thing is that you'll have to run autogen.sh and configure once
|
|
more to setup your build environment.
|
|
|
|
The good news is that if you are working on a single plugin then you will
|
|
find recompiling the plugin MUCH faster than recompiling a dissector and
|
|
then linking it back into Wireshark. Use "make -C plugins" to compile just
|
|
your plugins.
|
|
|
|
The bad news is that Wireshark will not use the plugins unless the plugins
|
|
are installed in one of the places it expects them to find.
|
|
|
|
One way of dealing with this problem is to set an environment variable
|
|
when running Wireshark: WIRESHARK_RUN_FROM_BUILD_DIRECTORY=1.
|
|
|
|
Another way to deal with this problem is to set up a working root for
|
|
wireshark, say in $HOME/build/root and build wireshark to install
|
|
there
|
|
|
|
./configure --prefix=${HOME}/build/root && make install
|
|
|
|
then subsequent rebuilds/installs of your plugin can be accomplished
|
|
by going to the plugins/foo directory and running
|
|
|
|
make install
|
|
|
|
5. Update "old style" plugins
|
|
|
|
5.1 How to update an "old style" plugin (using plugin_register and
|
|
plugin_reg_handoff functions).
|
|
|
|
The plugin registration has changed with the extension of the build
|
|
scripts. These now generate the additional code needed for plugin
|
|
encapsulation in plugin.c. When using the new style build scripts,
|
|
stips the parts outlined below:
|
|
|
|
o Remove the following include statements:
|
|
|
|
#include <gmodule.h>
|
|
#include "moduleinfo.h"
|
|
|
|
o Removed the definition:
|
|
|
|
#ifndef ENABLE_STATIC
|
|
WS_DLL_PUBLIC_DEF gchar version[] = VERSION;
|
|
#endif
|
|
|
|
o Move relevant code from the blocks and delete these functions:
|
|
|
|
#ifndef ENABLE_STATIC
|
|
plugin_reg_handoff()
|
|
....
|
|
#endif
|
|
|
|
#ifndef ENABLE_STATIC
|
|
plugin_register()
|
|
....
|
|
#endif
|
|
|
|
This will leave a clean dissector source file without plugin specifics.
|
|
|
|
5.2 How to update an "old style" plugin (using plugin_init function)
|
|
|
|
The plugin registering has changed between 0.10.9 and 0.10.10; everyone
|
|
is encouraged to update their plugins as outlined below:
|
|
|
|
o Remove following include statements from all plugin sources:
|
|
|
|
#include "plugins/plugin_api.h"
|
|
#include "plugins/plugin_api_defs.h"
|
|
|
|
o Remove the init function.
|
|
|
|
o Add a new Makefile.common file with the lists of source files and
|
|
headers.
|
|
|
|
o Change the Makefile.am and Makefile.nmake files to match those of
|
|
the DOCSIS plugin.
|
|
|
|
|
|
6 How to plugin related interface options
|
|
|
|
6.1 Implement a plugin GUI menu
|
|
|
|
A plugin (as well as built-in dissectors) may implement a menu within
|
|
Wireshark to be used to trigger options, start tools, open Websites, ...
|
|
|
|
This menu structure is built using the plugin_if.h interface and it's
|
|
corresponding functions.
|
|
|
|
The menu items all call a callback provided by the plugin, which takes
|
|
a pointer to the menuitem entry ad data. This pointer may be used to
|
|
provide userdata to each entry. The pointer must utilize WS_DLL_PUBLIC_DEF
|
|
and has the following structure:
|
|
|
|
WS_DLL_PUBLIC_DEF void
|
|
menu_cb(gpointer user_data)
|
|
{
|
|
... Do something ...
|
|
}
|
|
|
|
The menu entries themselves are generated with the following code structure:
|
|
|
|
ext_menu_t * ext_menu, *os_menu = NULL;
|
|
|
|
ext_menu = ext_menubar_register_menu (
|
|
<your_proto_item>, "TestMenu", "Some Menu Entry", TRUE );
|
|
ext_menubar_add_entry(ext_menu, "TestEntry1", "Test Entry 1",
|
|
"This is a tooltip", menu_cb, <user_data>);
|
|
ext_menubar_add_entry(ext_menu, "TestEntry2", "Test Entry 2",
|
|
NULL, menu_cb, <user_data>);
|
|
|
|
os_menu = ext_menubar_add_submenu(ext_menu, "TestSubMenu", "Sub Menu" );
|
|
ext_menubar_add_entry(os_menu, "SubEntry1", "Test Entry A",
|
|
NULL, menu_cb, <user_data>);
|
|
ext_menubar_add_entry(os_menu, "SubEntry2", "Test Entry B",
|
|
NULL, menu_cb, <user_data>);
|
|
|
|
The second parameter to ext_menubar_register_menu and ext_menubar_add_entry is
|
|
an internal definition for the menu, utilized by the GTK interface. It must not
|
|
contain any characters besides A-Z, a-z and 0-9.
|
|
|
|
Using the Gtk Version and a Mac OSX operating system, this will not work, and
|
|
the Gtk interface is currently not supported on this plattform. The Qt interface
|
|
on Mac provides the menu.
|
|
|
|
For a more detailed information, please refer to plugin_if.h
|
|
|
|
6.2 Implement interactions with the main interface
|
|
|
|
Due to memory constraints on most plattforms, plugin functionality cannot be
|
|
called directly from a DLL context. Instead special functions will be used, which
|
|
will implement certain options for plugins to utilize.
|
|
|
|
The following methods exist so far:
|
|
|
|
/* Applies the given filter string as display filter */
|
|
WS_DLL_PUBLIC void plugin_if_apply_filter
|
|
(const char * filter_string, gboolean force);
|
|
|
|
/* Saves the given preference to the main preference storage */
|
|
WS_DLL_PUBLIC void plugin_if_save_preference
|
|
(const char * pref_module, const char * pref_key, const char * pref_value);
|
|
|
|
|
|
|
|
----------------
|
|
|
|
Ed Warnicke <hagbard@physics.rutgers.edu>
|
|
Guy Harris <guy@alum.mit.edu>
|
|
|
|
Derived and expanded from the plugin section of README.developers
|
|
which was originally written by
|
|
|
|
James Coe <jammer@cin.net>
|
|
Gilbert Ramirez <gram@alumni.rice.edu>
|
|
Jeff Foster <jfoste@woodward.com>
|
|
Olivier Abad <oabad@cybercable.fr>
|
|
Laurent Deniel <laurent.deniel@free.fr>
|
|
Jaap Keuter <jaap.keuter@xs4all.nl>
|