Allow me to voice some agreement here. I would LOVE to see ethereal
evolve towards a tool which has the libethereal tools + dissectors as
its core, a basic sniffer interface like that which we have already,
and the ability to add tools via plugins. I can think of a half a
dozen different tools that USE the dissection and filtering capacity
of ethereal. I see the steps as something like the following:
1) Split off libethereal + dissectors and libwiretap from
ethereal proper. Until we have a clean split and a clean
API the plugins are just going to make things messier.
2) Clean up libethereal and write a clean API.
3) Consider to what degree it makes sense to rework the
dissectors to handle the API correctly ( can we banish pi
now?) and rework them.
4) Build some language bindings onto the API.
5) Put a plugin architecture into ethereal and associated tools
( not libethereal, in my view dissectors should plug into
libethereal, most tools probably shouldn't).
6) Document like mad men :)
I've wanted to carry out this program for some time. For 1)
to get completed requires munging through the symbols in libethereal
to see what dependencies on other ethereal things remain
due to externs and such. I've started doing some of that
analysis.
Does the above program sound reasonable? Is anyone else interested
in helping move in this direction?
Ed
On Sat, 14 Jul 2001, Pavel Mores wrote:
> 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
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
