Wireshark-dev: Re: [Wireshark-dev] colorizing sFlow
From: Ulf Lamping <[email protected]>
Date: Mon, 15 Oct 2007 23:21:23 +0200
Andrew Feren schrieb:
Hi Andrew!

Maybe I'm missing the point (I don't know sflow and you hesitate explaining what it is): if you are using UDP only, why is the "Bad TCP" rule triggering anyway?!?
The "Bad TCP" rule is triggering because there are sampled TCP headers in the
sflow packet and the TCP dissector is being called to display the information
in the TCP header.  (Well actually the ip dissector is being called, but it
eventually works its way down to TCP.)
An analogous situation is the headers included in ICMP error responses.  The
ICMP dissector also calls the ip dissector.  For ICMP this is less of an
issue since even if TCP headers were included in an ICMP error the packet
would be colored black in either case.

For sFlow it is normal operation to include headers.  Having packets marked
black that are 100% normal seems wrong.  The only reason the packets are
black is that the sequence numbers in the sampled headers don't happen to
sync up with anything else.
I'm not an expert on sflow/TCP/UDP to get an idea about it.

However, this sounds a lot like the TCP/UDP dissectors should (somehow) prevent this situation - and not the coloring rules.
BTW: The coloring rules wasn't meant as a normative reference, but as an example that coloring is possible.
OK.  Does that rule out making improvements?  I can just update my
environment and forget about it.
Not generally, but my feeling is that having lot's of exceptions to the coloring rules is not the way to go here. The problem here is that the TCP/UDP dissectors missinterprete stuff - and that should be fixed instead IMHO.
In the end having a set of coloring rules that someone can understand is 
a value in itself IMHO.
On a related note it would be nice if there were a way to know which rule
triggered a particular color.
I've implemented this some time ago, you'll find this under "Coloring Rule Name" of the Frame at the packet details pane.
Hope this helps,

Regards, ULFL