[Andrew Feren <acferen@xxxxxxxxx>]

I'd like to make/propose a change to the default colorization rules.

The scenario:
In sampled mode sFlow datagrams include the headers of sampled packets.  Wireshark very nicely calls the appropriate dissectors to nicely display the sampled headers.

The problem:
Many sFlow packets get colorized to reflect perceived errors from the sampled headers.  Black for "Bad TCP" is very common since we are only looking at a sample of traffic we can expect sequence numbers to be missing/unseen.

Possible solution:
Create a default colorization rule using the same color as UDP traffic and the rule "udp && sflow".  This would need to be the first rule in the list (or at least a head of "Bad TCP" which is first in my current install.

Caveats:
sFlow can be sent over TCP as well as UDP (I'm not using sFlow over TCP so I'm willing to ignore this for now ;-).  I'm not quite sure how to deal with this situation.  Creating
 a "tcp && sflow" rule ahead of the "Bad TCP" rule sort of defeats the purpose if there are errors in the sFlow TCP.  On the other hand having the contents of the sFlow message colorize tends to create a lot of noise and mask any real TCP errors.

Other thoughts:
Should there be a different color to indicate that colorizing has been short circuited.  So instead of colorizing sflow over UDP as UDP color all sflow (over UDP and TCP) in a unique way.  I'm not sure if there are other protocols that might need something like this.

Final question:
If I want to create a patch to change the default colorization which file(s) do I need to modify?

Thanks for any suggestions/thoughts/comments,
-Andrew


-Andrew Feren
 acferen@xxxxxxxxx