forked from osmocom/wireshark
7bd6bae799
Change-Id: I259fe24e6dca7679f22492161b0c4cd97c7521de Reviewed-on: https://code.wireshark.org/review/14145 Reviewed-by: Graham Bloice <graham.bloice@trihedral.com>
378 lines
11 KiB
Text
378 lines
11 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
|
|
moduleinfo.h
|
|
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 moduleinfo.h
|
|
|
|
Your plugins/foo/moduleinfo.h file is used to set the version information
|
|
for the plugin.
|
|
|
|
2.6 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 Custom.m4.example and
|
|
Custom.make.example files to files of the same name but without the ".example"
|
|
suffix. Now you have two Custom 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"
|
|
|
|
For CMake builds, either pass the custom plugin dir on the CMake generation
|
|
step command line:
|
|
|
|
CMake ... -DCUSTOM_PLUGIN_SRC_DIR="plugins/foo"
|
|
|
|
or copy the top-level file CMakeListsCustom.txt.example to CMakeListsCustom.txt
|
|
(also in the top-level source dir) and edit so that CUSTOM_PLUGIN_SRC_DIR is
|
|
set() to the relative path of your plugin, e.g.
|
|
|
|
set(CUSTOM_PLUGIN_SRC_DIR plugins/foo)
|
|
|
|
and re-run the CMake generation step.
|
|
|
|
To build the plugin, run your normal Wireshark build step.
|
|
|
|
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/wireshark.nsi
|
|
plugins/Makefile.am
|
|
|
|
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 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.3 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.4 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.5 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.6 Changes to the installers
|
|
|
|
If you want to include your plugin in an installer you have to add lines
|
|
in the NSIS installer wireshark.nsi file.
|
|
|
|
3.2.6.1 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.6.2 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 its
|
|
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(ext_menubar_gui_type gui_type, gpointer gui_data,
|
|
gpointer user_data _U_)
|
|
{
|
|
... 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>, "Some Menu Entry", TRUE );
|
|
ext_menubar_add_entry(ext_menu, "Test Entry 1",
|
|
"This is a tooltip", menu_cb, <user_data>);
|
|
ext_menubar_add_entry(ext_menu, "Test Entry 2",
|
|
NULL, menu_cb, <user_data>);
|
|
|
|
os_menu = ext_menubar_add_submenu(ext_menu, "Sub Menu" );
|
|
ext_menubar_add_entry(os_menu, "Test Entry A",
|
|
NULL, menu_cb, <user_data>);
|
|
ext_menubar_add_entry(os_menu, "Test Entry B",
|
|
NULL, menu_cb, <user_data>);
|
|
|
|
This will not work with the GTK version on OS X; the GTK interface is
|
|
currently not supported on this plattform. The Qt interface on OS X
|
|
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);
|
|
|
|
/* Jumps to the given frame number */
|
|
WS_DLL_PUBLIC void plugin_if_goto_frame(guint32 framenr);
|
|
|
|
|
|
|
|
----------------
|
|
|
|
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>
|