Ethereal-dev: Re: [Ethereal-dev] General plugins

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

From: Pavel Mores <pvl@xxxxx>
Date: Sat, 14 Jul 2001 14:59:18 +0200
On Fri, Jul 13, 2001 at 11:42:46AM -0700, Guy Harris wrote:

> > This is a neat idea. It would make programming such modules less
> > hackish. When I wrote the tcp graphing code I missed some sort of
> > internal (plugin, if you will) API that would enable me to say "dear
> > ethereal core, give me IP header of frame #66 or NULL if there isn't
> > any".
> 
> Hmm.
> 
> How about "dear Ethereal core, give me the protocol tree for this frame,
> give me the header field IDs of particular fields, and let me search a
> protocol tree for a particular field, and extract its value"?
> 
> That does mean a more expensive full dissection is required, though.

An API which would allow some code to actually *use* results of work of
ethereal core and dissectors is needed.

I've been following discussions on the list for some time now and I'd
like to tell you something. It seems to me that some of us are so
consumed by all of these fancy new dissectors and their supporting
infrastructure that they tend to miss the point of network traffic
analysis. Don't get me wrong, I'm not questioning efforts of dissector's
authors, I'm just trying to tell that ability to dissect packets is just
a source of input data and a necessary prerequisite for *true* analysis.
Not all problems can be solved by just examining some header fields of a
couple of packets. And yet this is the only thing that ethereal
currently supports. The TCP graphing code just scratches the surface of
what could be done. You have to be aware that dissecting is no be-all
and end-all of network traffic analysis. Support for some sort of API
I'm talking about, however limited, and a couple of obvious callback
points in the packet processing chain would enable people to use your
program in a way you've never dreamt of. This should be the ultimate
goal. Your job (a mine too) is not telling users the features they need
are impossible because architecture of the software would be
compromised, it's coming up with architecture that's clean and yet
featureful. Telling "this is impossible and that is ugly" won't get us
anywhere.

	pvl