SNMP is a good example of the difficulties of a very good machine generated
dissector.
One example:
A very good SNMP dissector should be able to find where an ARP table
is described in the SNMP transactions.
The content of this ARP table should be used to populate ethereals internal
table for
ethernet to ip address resolution.
Data inside conversations of one protocol will contribute to the state and
relations of packets
for other protocols.
There will soon be so many protocol/dissector specific special cases so that
it gets easier to
just write the dissector by hand instead of making a specific
SNMP-detect-arp-table-and-operate-on-it
compiler for the snmp dissector dissector.
----- Original Message -----
From: "Andrew Feren"
Sent: Wednesday, August 27, 2003 11:22 PM
Subject: Re: [Ethereal-dev] Re: Ethereal Gripe
>
> ----- Original Message -----
> From: "Ronnie Sahlberg"
> 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
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
