Ethereal-dev: Re: [Ethereal-dev] Bad Packet Handing (Was packet-diameter lock bug)

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

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Mon, 19 Feb 2001 13:14:06 -0800
On Mon, Feb 19, 2001 at 09:49:52AM -0600, David Frascone wrote:
> Ok, stupid question.  What should a dissector do when it discovers a bad
> packet?  Can I hilight the offending bytes in a color?

There is no way to highlight a bad field in color - and there will never
be a way for a dissector to explicitly say "highlight this in red"; for
one thing, there's no guarantee that the result of the dissection will
be used to display on something capable of displaying stuff in color. 
The color is a UI issue, and dissectors don't directly expose themselves
to the user in that fashion.

There should perhaps, however, be a way to mark a particular protocol
tree item as having an error in it (for example, an item for a checksum
could be so marked if the checksum is bad), however, so that whatever
application is using that dissector could, if possible, mark the field
as being in error, and so that one could construct a display filter that
shows frames with errors in them.

> Should I just return, since the rest of the packet is suspect?

The answer depends on what "bad" means.

If the packet is "bad" in such a way that the rest of the packet cannot
correctly be dissected - for example, if the packet claims that the
length of an attribute/value pair is 0, so that the "next"
attribute-value pair would be the same attribute value pair - then the
dissector should stop dissecting the packet, and perhaps put the length
field into the protocol tree with, say, "proto_tree_add_uint_format()"
and mark it as bad.

If, however, the packet is "bad" in such a way that the dissector can
still attempt to dissect the rest of it - for example, if some integral
field which is supposed to have a value from 1 to 5 has a value of 17,
or if a checksum field isn't valid - the dissector should continue
dissecting the packet.