Ethereal-dev: Re: [Ethereal-dev] Re: Ethereal Gripe

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Andrew Feren" <aferen@xxxxxxxxxxxxxxxxx>
Date: Wed, 27 Aug 2003 23:25:09 -0400
----- Original Message ----- 
From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
To: "Andrew Feren" <aferen@xxxxxxxxxxxxxxxxx>; "Kevin" <kem2@xxxxxxx>
Cc: <ethereal-dev@xxxxxxxxxxxx>
Sent: Wednesday, August 27, 2003 10:01 AM
Subject: Re: [Ethereal-dev] Re: Ethereal Gripe


> A tool might be useful to produce a better-than-nothing first-shot
dissector
> for ethereal.

Sure and if you'll pardon my continual use of an analogy from a different
domain I would say this is the moral equivalent of a MIB browser.  MIB
browsers spray information at you with only as much order as can be gleaned
from the MIB.  It isn't much, but it is a thousand times better than nothing
until you can get something better.

I think the same is true of protocols.  Getting Ethereal to automatically
generate code to at least label fields and interpret types correctly would
be way better than the alternative of looking at the raw hex dump.  Doing
this without recompiling would be great, but not necessary.

> When the dissector matures and gets state tracking and intelligence added
to
> it,  the problem space is just shifted from the dissector to the
> compiler/generator.

I agree, but I also think that this does not preclude autogenerating packet
decoding.

[ snip a good example of what an NFS dissector should do ]

> I am absolutely convinced that it is more difficult and requires more
effort
> to develop a protocol description language that is rich enough
> to describe these relations htat i described than to code these relations
by
> hand.

I agree!  I don't think we should even try.  I think we should forget about
autogenerating dissection and consider autogenerating good packet decoding
(to be used by dissectors).

-Andrew