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: David Frascone <dave@xxxxxxxxxxxx>
Date: Mon, 19 Feb 2001 16:01:27 -0600
On Mon, Feb 19, 2001 at 01:14:06PM -0800, Guy Harris wrote:
> 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.

Yeah, I was hoping for something nice like that *grin*

> 
> > 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.

Actually, what I mean by bad packet is that reserved bits are set, lengths are
wrong, etc.  What it *usually* means is that a packet has been fragmented,
and that we're starting to try to dissect in the middle of a packet.

Also, I do not dissect the last AVP in a truncated list of AVPs.

It is MUCH cleaner now . . . You'll probably get diffs today.


-Dave