Ethereal-dev: Re: [ethereal-dev] idea for a 'standard' way of handling unknown data
Gilbert Ramirez wrote:
>
> On Wed, Dec 08, 1999 at 05:07:22PM -0600, Neulinger, Nathan R. wrote:
> >
> >
> > What I would love to be able to do (for development purposes) is do a
> > filter
> > of "unknown" and have it filter out all the packets that are deemed to be
> > fully and correctly decoded.
> >
> > It could be done by having a dissect_unknown() routine, or always adding a
> > proto_tree item for "unknown". This would allow someone to quickly see what
> > needs work. Things like unknown subprotocols, unknown ipx sockets (outside
> > the dynamic ranges of course), etc. Just a thought.
>
> Yes, that sounds very useful. Perhaps get rid of dissect_data() and provide
> dissect_data_known() and dissect_data_unknown() for the new functionality, and
> to find all the cases in the dissectors where dissect_data is used.
>
> The print routines check for proto_data to determine where to start printing
> a hex dump, so either both dissect_data_known() and dissect_data_unknown()
> hav eto use proto_data and differentiate the "knownness" via another field,
> or we'll have print.c hceck for a "proto_data_known" and "proto_data_unknown"
> protocols.
One concern would be - suppose you have a packet that consists of:
chunk 1
len1
data of length len1 that isn't dissected yet
chunk 2
len2
data of length len2 that isn't dissected yet
We'd probably need to have some way of telling it to dissect only a
certain range of bytes.
An example of the above might be a DNS reply where the overall structure
is known, but you might not know how to dissect an individual component
yet. Say a new type of record.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: nneul@xxxxxxx
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216