Writing a tool to parse data and generate a generic ethereal dissector is
reasonably easy,
I have emacs macros and shellscripts that do 80-90% of this work for say
converting a DCE IDL file into
a semifunctional ethereal dissector that can be massaged into actually
compiling and working.
I fear however that it will never be able to generate truly great
dissectors.
Useable as a one-shot generation of a dissector that can alter be enhanced
to become good,
but after it has been enhanced to be good, one can never machine regenerate
the dissector from the
description again.
However, this is the easy part, therse things that just decodes the actual
packet but this does imho not make a good
dissector.
The difficult part is those parts that can not be described in a generic
packet/interface description language such
as how and what state should be maintained between packets. How packets
relate to eachother.
What information should go in COL_INFO.
Things that makes the difference between a merely reasonable dissector and a
truly excellent one, such as:
ONC-RPC request/response matching.
Response time measurement.
Teaching NFS dissector how to discover the mapping between filehandles and
filenames
Teaching the SMB dissector the various ways and combinations wich can be
used to encapsulate DCE PDUs ontop of SMB
etc etc
the extra things that makes the dissector very good but at the same thime
are the things that can not be described
in a packet description language since it requires a human to understand
and come up with the extras.
----- Original Message -----
From: "Ed Warnicke"
Sent: Thursday, August 21, 2003 7:08 AM
Subject: Re: [Ethereal-dev] Re: Ethereal Gripe
> It strikes me that generally you've got a few families of
> protocols:
>
> 1) Fixed width binary fields
> 2) RFC 822 derived ( HTTP, SIP, MGCP, etc)
> 3) TLV based
> 4) ASN.1 ber/per encoded
>
> Most of these shouldn't be that hard to handle as generalized
> cases... but everytime I find myself saying that I think of
> DNS and DNS compression... there will always be oddballs...
>
> Ed
>
> On Wed, 20 Aug 2003, Ashok Narayanan wrote:
>
> >
> > That's a little tough; freeform protocols are somewhat harder to deal
> > with.
> >
> > A lot of IETF protocols are going to this "TLV" type of message like
> > used in RSVP. The message is a series of objects; each object has a
> > type, a subtype, and a length (not necessarily in that order). Each
> > object has a separate definition.
> >
> > Maybe some sort of XML parser that describes these objects, and the
> > header? I was thinking about it some time back but gave up due to lack
> > of time. Maybe I (or somebody) can dig up this chestnut again...
> >
> > -Ashok
> >
