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