Guy Harris wrote:
On Sat, Sep 20, 2003 at 11:04:49AM +0200, Matthijs Melchior wrote:
Yes, I have been experimenting with an enum added to field_info and
using that to set the background color of protocol tree item.
What are the values of the enum?
MATCH_NONE, MATCH_TOUCHED, MATCH_TRUE, MATCH_FALSE
I.e., it presumably means you can tag fields as more than just errors;
what other tags can be applied? (Or is it an enum with two values now -
"OK" and "Error" - and the possibility of adding more values?)
In my current code, only MATCH_TOUCHED is implemented. That is set when
the value of field is read, and if that field is not visible then an
attempt is made to find a visible field describing the same first byte.
I am still thinking how to implement the other values, how to associate
the result of a test with an actual field, and how to mark a field that
was just tested for its presence.
This color
is also applied to all enclosing pdu's in order to notice the presence
of a property without having to expand all sublevels.
By "enclosing PDUs" do you mean the protocol layers above the one that
got the error? Or did you mean "enclosing protocol tree items"?
Yes, that is what I mean, the recursive display code will apply the color
on its way back up to the parent items of a leaf with color.
This enum is to be set based on the outcome of the packet selection
expression and your proposal would be implemented using the following:
"tcp.checksum_bad == 1 || frame".
Why "|| frame"? That's true of every packet, so that expression always
evaluates to "true", right?
Yes, this is a trick to select all packets, and not just the ones with an
incorrect checksum. When indicating the bad checksum with a color, this is
what you want, it gives an indication about the error rate.
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".
Yes, we need to think about this much more....
When thinking about how to continue with this, the following occured to me:
The 3 instances of the color selection dialogue together with the font
selction dialogue could be combinded in one style-selection dialogue.
And everything that is displayed on the screen will use some style to do
so. This style would contain 3 colors [field background, text background
and text foreground] and a font. The colorize display dialogue would
associate a style with an expression, the TCP Streams dialogue would
associate a different style for each party in the conversation, a
marked frame would use a style, the hex display would use two styles
and some new stuff or just the selection expressions with embedded
color directives would provide style info for protocol tree items.
Of course, this is quite a bit of work, designing and implementing...
And, having these styles would ease further developement of the
colorization of the protocol tree items....
--
Regards,
---------------------------------------------------------------- -o)
Matthijs Melchior Maarssen /\\
mmelchior@xxxxxxxxx Netherlands _\_v
---------------------------------------------------------------- ----