On 1/30/07, Mark H. Wood <mwood@xxxxxxxxx> wrote:
ASN.1 was designed specifically for that sort of thing.
Not really. ASN.1 is a standard description format for new protocols.
It is not designed to, nor is it capable of describing arbitrary
existing protocols. If a new encoding were arrived at, maybe, but you
would probably end up needing extensions to ASN.1 as well.
NetPDL or things like it are the way to do this. However, it is not
realistic to think that you will never need to have hooks in the XML
descriptors for custom code. For example, say Protocol X uses some
funny encoding for a field that no one else uses (beyond just shifts
and ORs of bits). Also the order in which decoding is done may be
important. You can have one decode step at the beginning followed by a
relatively normal packet disassembly. Sequence, iteration, algorithms,
etc. are more naturally handled in code than XML document (that didn't
stop the abomination that is XSLT though ;-) ).
That's not a reason not to attempt this. A generic description would
take you pretty far with most protocols and obviate most of the code
in Ethereal dissectors, presumably making it easier to maintain
(though it would probably take longer to load). Just make sure that
hooks are provided to easily decode formats that were not considered.
Perhaps the XML documents could be compiled during the build process
to C structures and initialization code.
-- John.
