----- Original Message -----
From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
To: "Ed Warnicke" <hagbard@xxxxxxxxxxxxxxxxxxx>; "Ashok Narayanan"
<ashokn@xxxxxxxxx>
Cc: <>
Sent: Wednesday, August 20, 2003 5:33 PM
Subject: Re: [Ethereal-dev] Re: Ethereal Gripe
> 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.
One possible way around this problem that I have used successfully in the
past is to add one more layer. Auto generate a "protocol" module or object.
This object understands only the names of the fields and the encoding
scheme. The dissector would then request the values by name. Now your
dissector can do all the custom work it wants to. If the protocol changes
and you regenerate the protocol module your dissector should still work.
New fields are ignored until the dissector is updated and naturally your
original dissector is robust enough to gracefully handle fields that no
longer exist. ;-)
When I used this method before it was in the context of developing element
management using SNMP. This domain had the distinct advantage of having
MIBs described in ASN.1 that were (to a greater or lesser extent) parsable
to begin with and contained all the information we needed extract data from
the device. For the protocols I have had to deal with I would first have to
create a parsable description of the protocol.
This all also assumes that a module can be autogenerated that provides all
the neccessary functionality without hand tweaking. If that can not be done
you are more or less back where you started. Seems like it should be doable
though.
> 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.
Right and all this stuff can, I think, be done without actually knowing how
the fields in a message are encoded.
-Andrew
