--- Joerg Mayer <jmayer@xxxxxxxxx> 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
obvious.
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
-Andrew Feren
acferen@xxxxxxxxx