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 _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
