Wireshark-dev: Re: [Wireshark-dev] colorizing sFlow
From: Andrew Feren <[email protected]>
Date: Tue, 16 Oct 2007 08:54:29 -0700 (PDT)
--- Joerg Mayer <[email protected]> wrote:

> On Mon, Oct 15, 2007 at 11:21:23PM +0200, Ulf Lamping wrote:
> > 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.
> IMO we need something like a protocol-as-payload flag to set at
> some point into the dissection: It should have several meanings:
> a) From now on dissection may break at any time and it's not an error
> b) Don't update the info column any more
> c) not relevant to filters (or just color-filters?)

Now that I understand this a bit better I see that this is really a filter
issue not a colorization issue.  Colorization just makes the filter issue

I think a protocol_as_payload flag may be the right approach.  The problem is
that it looks like it could become a giant game of code whack-a-mole.

Sake suggested looking in packet-ip.c for an example of using
"pinfo->in_error_pkt".  This boils down to a specific instance of protocol as
payload.  I implemented these few lines in sFlow and sFlow packets were no
longer highlighted as TCP errors.  However, now they are highlighted as SMB. 
If I remove the SMB rule they show up as HTTP, DCERPC, TCP, arp, etc.  I even
see one matching "tcp.flags & 0x02 || tcp.flags.fin == 1".  Could be just
about anything depending on what headers happen to get sampled.

Using pinfo->in_error_pkt is a step in the right direction, but I'd still
like   to find a more complete/general solution.

> Does this make any sense? Would it be doable?

Makes sense to me.  

As for being doable ... Probably not all in one sitting, but I guess it could
be done in phases as any particular protocol causes heartache for someone.


-Andrew Feren
 [email protected]