S. Faizi wrote:
I wanted to highlight certain messages as red, blue or green. So,
following the advice of this list, I added three hidden fields:
...
Then as the packets are received by ethereal, I do a quick check and set
the appropriate field:
E.g:
switch (scap_msg_type) {
case CDMA_SDF_Release_Resource:
release_cause = VALUE16(tvb, offset + 32);
/*fprintf(stderr,"Release Cause: %04x",release_cause);*/
/*if not normal release tag it red */
if ( release_cause != 0x1100 ) {
/*fprintf(stderr,"Frame: %d, Release Cause:
%04x\n", pinfo->fd->num, release_cause); */
proto_tree_add_boolean_hidden(tree, hf_scap_red,
tvb, NULL, NULL, TRUE);
} else {
proto_tree_add_boolean_hidden(tree,
hf_scap_blue, tvb, NULL, NULL, TRUE);
}
Are "scap_msg_type" and "release_cause" items in the protocol tree?
If so, you could do a color filter *without* adding those fields:
scap.msg_type == {the value for CDMA_SDF_Release_Resource}
&& scap.release_cause == 0x1100
to color the packet red, and
scap.msg_type == {the value for CDMA_SDF_Release_Resource}
&& scap.release_cause != 0x1100
to color the packet blue.
Then I defined the following filters (from colorfilters)
@Scap_Red@scap.display_red == 1@[65534,5708,8553][0,0,0
<mailto:1@[65534,5708,8553][0,0,0>]
@Scap_Blue@scap.display_blue == 1@[2506,58883,65534][0,0,0
<mailto:1@[2506,58883,65534][0,0,0>]
The problem I have is that messages at random are showing up in
different colors, or all messages show up in the same color (see the if
statement above). I noticed if I change the order of the filters (i.e.
put blue first and then red) it somewhat seems to colorize as I want. I
only added the hf_scap_blue because all of my messages where getting
displayed in red.
Can a single packet have more than one message of type
CDMA_SDF_Release_Resource in it? That might be the case if, for
example, it's transported over TCP. If so, then a packet might match
more than one filter - the last one evaluated that matches wins.
Also, I noticed cpu utilization goes up quite a bit with colorize
display. Is this normal?
Yes. If you aren't colorizing the display, when reading in the capture
file Ethereal doesn't have to construct the protocol tree for the
packets, but, in order to evaluate a color filter, it has to construct a
protocol tree, which means it uses more CPU.
