Hi,
I've been thinking about implementing plugins support in ethereal. This
would be useful for me, because I'm working for a company which uses a
"private" protocol on its network, and they won't allow writing a GPLed
dissector for it.
Here is the design I started working on :
The plugin is a shared object file, which must provide :
- string constants :
- name : the plugin name
- desc : a description
- protocol : the name of the underlying protocol
- filter_string : string using dfilter syntax. Describes the packets
which the plugin's dissector should be called
- two functions :
- proto_init : plugin initialisation (can be used to register
protcols)
- dissector : the dissector itself
Ethereal loads the plugins using dlopen. It stores various informations
about the plugin in a linked list of structures :
typedef struct _plugin {
void *handle; /* handle returned by dlopen */
gchar *name; /* plugin name */
gchar *protocol; /* protocol which should call the dissector
* for this plugin */
dfilter *filter; /* display filter matching frames for which
* the dissector should be used */
/* the dissector */
void (*dissector) (const u_char *, int, frame_data *, proto_tree *);
struct _plugin *next; /* forward link */
} plugin;
In normal ethereal dissectors, we must look for plugins for the current
protocol in the linked list, and call the dissector if the packet passes
the filter.
Maybe, if everyone here agrees, we could allow a linux kernel like
exception allowing binary only plugins in ethereal.
But even if you don't wish to allow it, plugins could be useful in some
situations : for example, if we used a plugin version of dissect_http,
the user could dynamically modify the filter_string used by the plugin
in order to decode http on a specific TCP port.
I should have an implementation ready for tomorrow.
Olivier
--
It wasn't exactly a divorce -- I was traded.
-- Tim Conway
