["Maynard, Chris" <Christopher.Maynard@xxxxxxxxx>]

If you just want to clean up the colorization, why can't you simply add a new coloring rule for sFlow above any of the others?  The first filter that matches is the coloring rule that is applied.
 
And to avoid a display filter match of "ip.src == 10.1.1.1" when sFlow traffic is present, can't you just use this filter instead, "!sFlow && ip.src == 10.1.1.1", wouldn't it?
 
These suggestions won't help your other issues, but they should solve your coloring and display filter problems, shouldn't they?

________________________________

From: wireshark-dev-bounces@xxxxxxxxxxxxx on behalf of Andrew Feren
Sent: Tue 10/16/2007 3:44 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] colorizing sFlow




--- Sake Blok <sake@xxxxxxxxxx> wrote:

> On Tue, Oct 16, 2007 at 08:54:29AM -0700, Andrew Feren wrote:
> >
> > > 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.
>
> Maybe if the sFlow dissector has a preference to en/disable dissection
> of it's payload would do the trick? I haven't looked at the code of
> the sFlow dissector, but this should be rather straightforward.

I could add a preference like this.  Might even be a good idea, but truth be
told I like being able to see the payloads dissected so this doesn't help me
much.

> > 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.
>
> If it's just the coloring of payload inside the sFlow packets that you'd
> like to disable, you could add a coloring rule at the top of the rule-list
> (or after the coloring rules that you do want to apply to these packets)
> that just colors sFlow packets with your default colors.

This thread started out with my wanting to just disable colorization of
sFlow.  However, now that I have looked at this more I realize that the
strange colorization is just a symptom of the way filtering is done.

> > > Does this make any sense? Would it be doable?
> >
> > Makes sense to me. 
>
> Well, yes and no. One might want to see the payload being colored
> others like yourself might not. If just disabling payload-dissection
> suits your needs, I think it could be a nice enhancement to have
> a preference setting for it.

A couple of clarifications

First a bit about sFlow.  sFlow is a flow monitoring protocol sort of like
NetFlow.  The difference (for this discussion) is that NetFlow pulls info
from packet headers and puts it into NetFlow defined fields.  sFlow in sample
mode selects a sample of headers from various conversations and bundles them
into a single packet like this

[IP [UDP|TCP [ sflow headers [header samp1][header samp2]...[header sampN]]]]


As you can see sFlow can have headers from multiple conversations in a single
packet. (I don't think there is a defined max, but assuming an MTU of 1500 a
practical max is probably around 10.  I have captures with as many as 9
different packet headers in a single sFlow packet).

If just the payload was being highlighted this would not bother me.  My
initial  problem was that highlighting percolated up to the top level.  It is
a bit confusing to look at a UDP packet claiming to have TCP errors or having
the Protocol column clearly labeled as sFlow, but coloring potentially being
almost anything from the colorization choices.  (my sFlow captures look like
"angry fruit salad" ;-)

Further more colorizing the payload headers would be more interesting/useful
if *all* of the payload headers colorized.  In practice what happens is only
the first  payload header that matches something interesting gets colorized.
This may or may not be the first payload in the capture.  If each sample in
an sFlow packet could be colored to indicate details of that sample, but not
percolate the changes up that would be very cool (not what I was originally
looking for, but still cool).

To get away from the colorizing aspect of this let me give a different
example.  If I use a filter like "ip.src == 10.1.1.1" this will find every
sFlow packet where *any* of the payload headers contain 10.1.1.1 as a src
addr.  I think this may not be the desired behavior.  It can certainly be
confusing since the ip.src being found is buried about 3 subtrees deep and
the  subtrees might be under any one of the sampled (payload) header trees.
It is certainly not quickly obvious why the filter matched.

Thanks,
-Andrew

-Andrew Feren
 acferen@xxxxxxxxx
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev





-----------------------------------------
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.

<<winmail.dat>>