It's definitely do-able to have an automated tool to write dissectors
for you. Of course each tool will require a very specific input format.
idl2eth does that creates dissectors from IDL files.
I wrote a tool in the past that is far too specialized to be helpful for
standard packet formats... but was used to generate 122 dissectors with
(extremely poorly named) filterable expressions (for use with stuff
similar to io_stat) and enumerated values...
Before you write any tool, I'd recommend writing a dissector or two by
hand in order to make sure that you recognize all the changes that are
required.
Unless you are working with a particular subset of protocols, you may
find that it is fairly complex to handle every possible variation in how
stuff is done. packet-udp is simple, except that it contains a CRC.
packet-udp also allows for sub-dissecors which may be an added headache
that you might be able to avoid... Packet-udp might even be too simple
in other ways... it has no flags in the header, has no enumerations of
any kind, and is completely fixed length.
I would consider packet-udp to be "almost" simple... it is fixed length
everything... the only non-standard thing is the CRC check that is done.
packet-dns.c contains strings and what-not and would be a bit more
complex to handle. packet-udp might even be too simple since it
contains no enumerations, no flag bits, and no variable length anything.
packert-dns does contain enumerations but appears to have been around
for too long... it doesn't use the full capabilities of the
hf_register_info structure. It also contains pdus and variable length
strings which might complicate matters.
packet-eth.c would be simple except for multiple standards for ethernet
packets... you probably could ignore the capture_* stuff...
Good luck in your quest... unless you have a very specific subset to
work with (such as GIOP stuff using IDL or my military-specific
packets), you are likely to find that the task of handling all protocols
even the (almost) simple ones, might become too complex of a task.
Maybe if done right, there could be a mechanism for adding extra code as
needed to handle non-conforming aspects of protocols. Whatever you come
up with, I'm sure others will probably be interested in what you did...
especially if it can completely handle your examples: packet-udp and
packet-dns...
"Ph. Marek" wrote:
>
> Hello everyone!
>
> I'm afraid that this is a dumb question but has someone done some work to make
> dissector writing easier?
>
> I'm thinking about eg a perl-script which gets a c-structure and some base
> data (has to be udp packet, on port x, with packet data byte y=z) which
> builds a dissector out of this.
>
> I just had a look (in CVS) into packet-dns and packet-udp (which I believed to
> be some simple dissectors - but I think I'm wrong :-) and was astonished.
> I know that the code is straightforward but the simple work of catching every
> change is what holds me back. If there's some script which generates this
> data from a c source it would take some work from me.
>
> Or the other way round:
> how about building a dissector which ain't attached anywhere by default. It is
> configured by a data file (text, generated eg. from c structures by a
> perl-script) and applies this data to user-defined packets - this is possible
> today, IIRC. (specifying which dissector to use on a class of packets, that
> is).
> I know that that would be slow but it would be the most dynamic - no more
> recompiling, ...
>
> And this preformatted text-files could then, when the development is over, be
> converted into c source for speed reasons ...
>
> Regards,
>
> Phil
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
