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