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