Wireshark · Ethereal-dev: RE: [Ethereal-dev] Re: Ethereal Gripe

[Richard Urwin <RUrwin@xxxxxxxxxxxxxx>]

In my (very) humble opinion, an automatic generation method that just
handled breaking out fields would be a huge help. It certainly beats not
having a dissector at all. Some people, who could write a protocol
description, can not write C.

If care were taken to produce well structured and modular code then it would
be easy to:
a) Use the unmodified dissector to read field values and use display and
color filters on them.
b) Add minor hand-crafted bells and whistles to the automatically generated
code and not have to re-do them after rerunning the generation. - Or only to
modify for fields that have changed. I don't see the hand-crafted code
standing alone from the automatically generated code, so there's no need for
interface versioning.
c) Migrate the automatically generated code to hand-crafted status when more
than bells and whistles were required, without having unmanageable spaghetti
to hand-craft.

So it would not be necessary to throw away previous work when the dissector
needed to be improved.

I don't see this as using ASN.1 or any other standardised notation. That
could be another layer - "convert ASN.1 to a format suitable for the
automatic dissector generator." If a single dissector is required then
writing a description of it in a bespoke format would be as easy as using a
standardised language. If it already exists in ASN.1 then it would be fairly
trivial to translate it even by hand. Only if several protocols were being
done at one time would it become onerous. Of course if we have supported
language X then you can be sure the protocols you want will be documented in
language Y anyway.

--
Richard Urwin, Private
"No 9000 series computer has ever made a mitsake or corrubiteddatatato."





> -----Original Message-----
> From: Ronnie Sahlberg [mailto:ronnie_sahlberg@xxxxxxxxxxxxxx]
> Sent: 27 August 2003 15:02
> To: Andrew Feren; Kevin
> Cc: ethereal-dev@xxxxxxxxxxxx
> Subject: Re: [Ethereal-dev] Re: Ethereal Gripe
> 
> 
> A tool might be useful to produce a better-than-nothing 
> first-shot dissector
> for ethereal.
> 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.
> When a dissector reaches the state where the current NFS 
> dissector is I fear
> that there is no way
> a machine can generate the state that dissector keeps track of:
> 
> 
> Portmapper GetPort  might tell us that NFS is spoken on port 456
> NFS Lookup tells us that the filehandle:abc refers to the 
> file "my file"
> 
> NFS write request in packet 7 contain the filehandle abc
> NFS reply in packet 12   is the reply to the request in packet 7
> 
> 
> the filter:   nfs.file=="my file"     will with ethereal 
> match  both packet
> 7 and packet 12.
> 
> it matches packet 7 because packet 7 contains a filehandle 
> that maps to the
> filename "my file"  which was discovered in some
> other nfs transaction.
> it matches packet 12  since packet 12 is a reply to packet 7 
> and packet 7
> contains a filehandle that maps to the filename we are searching for.
> 
> 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.
> note that ethereal already today can do these things for nfs.
> If the protocol description language becomes too rich and 
> feature filled, it
> might become too complex to use to describe the protocol and the
> protocol pdu relations.
> the complexity and work has only been moved from implementing 
> the dissector
> into describing the dissector in a special language through an extra
> layer of indirection.
> 
> 
> 
> With this extra layer of indirection between the protocol 
> description and
> the resulting ethereal dissector implementation
> the complexity increases.
> 
> 
> many ethereal developers have thought long and hard over the issue.
> 
> 
> it is a very hard problem to solve.
> 
> 
> 
> ----- Original Message -----
> From: "Andrew Feren"
> Sent: Tuesday, August 26, 2003 11:26 PM
> Subject: Re: [Ethereal-dev] Re: Ethereal Gripe
> 
> 
> >
> > ----- Original Message -----
> > From: "Kevin"
> > Sent: Sunday, August 24, 2003 9:52 AM
> > Subject: Re: [Ethereal-dev] Re: Ethereal Gripe
> >
> >
> > > Comment from a heavy user of ethereal.  I am not a 
> developer in any
> > > manner, but my team and I do use ethereal daily.
> > >
> > > Acterna Examine has / had the ability to insert a user definable
> > > protocol layer into the decode.  Then filters can be 
> applied to this
> > > layer using the defined field names.
> > >
> > > Just the ability to break out and display these proprietary or new
> > > fields is a godsend.  Any relationships between the fields is
> > > determined by the user.
> >
> > I agree.
> >
> > It was the inability of the sniffer we were using to do 
> this that drove me
> > to discover and begin developing ethereal dissectors.  I 
> agree with Ronnie
> > that just decoding the packet doesn't make a good 
> dissector.  However, if
> a
> > good dissector is not available the ability to break out and display
> > new/proprietary fields would be fabulous.  In some cases it 
> might even be
> > all that is needed.
> >
> > -Andrew

________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________