Ethereal-users: Re: [Ethereal-users] wish-list addition

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Thu, 13 Sep 2001 15:40:19 -0700 (PDT)
> I have an idea for addition to ethereal: diagnostics
> of what is traced!
> E.g.: see that for example an ip-address is
>   used by more then 1 MAC address
> e.g.2: see that a certain host is sending corrupted
>   data
> etc.

That's an open-ended request, so I think what'd be needed there would be
a way of plugging in diagnostic modules of that sort, rather than just
specific diagnostics.

This was discussed a while ago; my inclination would be to have a
mechanism to add a second type of plugin (over and above the dissector
plugins currently supported), which would:

	register themselves by name (whether they'd appear as menu items
	under "Tools", or in a dialog box with a list from which you
	could select, or in one or the other (or some other place)
	depending on what the plugin requested, is another matter);

	register a routine to be called when selected;

	have a routine they could call to request that a pass through
	all packets be made, and possibly also supply a display filter
	expression to limit which packets would be processed;

	register a routine to be called for each packet (called, for
	example, when the protocol tree for the packet was constructed,
	with that protocol tree as an argument, and with the ability to,
	for example, get a handle for particular fields, by name, and
	to find all instance of a field in the protocol tree);

	register a routine to be called when the processing is finished.

One might have a way to indicate whether the plugin is for Tethereal (in
which case it'd have to write its analysis to a file, or to the standard
output with the regular packet detail output suppressed), or Ethereal
(in which case it'd use whatever graphics toolkit that version of
Ethereal was built with - currently GTK+, but others might be used in
the future).

I wouldn't want to permanently restrict it to plugins written in
compiled languages, and built into run-time loadable objects, though;
people might want to write them in Perl, or Python, or Ruby, or
{Visual,GNOME,etc.} Basic, or....