Hi all,
My intention was indeed to enable tracking of bogus fields in the tree view,
and allow colorization based on the correctness of the field. For example,
we could then check whether a protocol PDU/SDU is still valid while the
checksum field is bogus (typical situation on TCP captures with checksum
computation offloading on the capture interface).
As Melchior proposes, we could use a top-level protocol error state which
would be enabled if a protocol field contains errors. We could for example
perform a bitwise OR of all error "fields" in order to compute that
protocol's top-levzl error "field".
We could define global (aka. Ethereal-own) and per-protocol error types in a
bit field, and assume the protocol field is OK when no bits are set. For
example, the highest-order byte from a guint32 could be reserved for
Ethereal while the remaining lower-order 24 bits could be used for the
specific protocol. This would allow a 2-stage realization of the proposed
feature (step 1: guint as boolean; step 2: guint as bit field).
I would make the distinction between critical and non-critical errors. For
example, a checksum error is often non-critical while a bogus length field
almost always is. Typically a critical error stops protocol dissection.
Should we update the error structure if an out-of-bounds exception occurred?
Regards,
Olivier
-----Original Message-----
From: Guy Harris
Olivier suggested a Boolean for a field that's independent of its value,
so that you could have, for example, a bogus packet type value, or an
incorrect length field, or... marked as an error; an incorrect checksum
would also be so marked.
If we did that, we should probably have a display-filter expression that
evaluates to "true" if a packet contains a field marked as "bad"; with
that, the protocol tree item colorization filter expression could be
just "error" (or something such as that). That'd also let you filter
for bad packets, and find bad packets with "Find Frame".
