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