Hi,
A thought.
Instead of reinventing the wheel for every type of packet: instead of
dissecting the ip header again in
a hypothetical plugin, couldnt the plugin instead just call the normal
dissect routine and then access the various fields
by searching for the appropriate hf_* fields for that packet instead?
If so it would be possible for the plugin to automatically use any field in
any packet type known to ethereal
(at least the packets which has hf_* fields defined).
This could make the hypothetical plugin automatically aware of every
different packet ethereal knows about without
duplicating the packet-*.c file for the plugin.
----- Original Message -----
From: "Pavel Mores" <pvl@xxxxx>
To: "Guy Harris" <gharris@xxxxxxxxx>
Cc: "Ed Warnicke" <hagbard@xxxxxxxxxxxxxxxxxxx>; "Guy Harris"
<guy@xxxxxxxxxx>; "Christopher Kelley" <kelley@xxxxxxxxxxxxx>;
<ethereal-dev@xxxxxxxxxxxx>
Sent: Monday, July 16, 2001 6:39 PM
Subject: Re: [Ethereal-dev] General plugins
> On Sun, Jul 15, 2001 at 11:37:09PM -0700, Guy Harris wrote:
>
> > On Sat, Jul 14, 2001 at 06:38:02PM -0400, Ed Warnicke wrote:
> > > Yes. For example one might put in a post dissection point into the
> > > api so that I could register a function with ethereal that gets called
> > > after a packet is dissected. Then I could add a plugin that would
> > > query each dissected packet to gather statistics.
> >
> > Hmm.
> >
> > Would this be for use when Ethereal first reads a capture file, or would
> > it be for, say, a Tools menu item that makes a new pass through the
> > capture?
>
> Could this be handled in the same manner as UI events?
>
> When user clicks on a packet in the packet list ethereal performs
> dissection and displays the protocol tree for that packet. Could this
> model apply to plugins, too? When a plugin needs to dissect a packet it
> would be dissected and returned to the plugin. The scheme could be
> optimalized in a number of ways. E.g. if some performance can be
> obtained by dissecting all of the dump at once instead of dissecting
> packets one after another as plugin code requests them then the ethereal
> plugin API could provide a plugin with a way of telling "I'm going to
> need the protocol trees for all of the packets so do it now". Or, the
> dissection process could consist of separate stages so that if a plugin
> just needs to compute some Ethernet stats it can request dissection of
> link layer only - there's no need to bother with full dissection of e.g.
> SMB headers in that case. Applying this to my TCP graping code, if the
> core could just give me a pointer (or an offset) into the raw packet
> data where the IP header begins I would be perfectly happy and yet a
> better part of expensive full dissection would be avoided. Once I have
> my IP hdr pointer I can do the rest of "dissection" very efficiently
> myself.
>
> pvl
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
