> I probably misunderstood you. You want those packets to follow the
> usual coloring rules and not be changed when colorizing a single
> conversation, right? I don't think that's possible; someone would need
> to change the code that colorize by conversation.
Thanks for responding - I am humbled :)
I was probably not clear in my description. Maybe the best way to describe my desired effect is that the coloring rules would take precedence over the colorize-by-conversation rule. Based on my testing, it seems that the colorize-by-conversation rules ignore the coloring rules. And I'm a little embarrassed to admit that I seem to have found a way shortly after my initial post by simply creating a new coloring rule with the following expression:
tcp.stream eq 7 && (!(tcp.flags & 0x02) || tcp.flags.fin != 1)
which has my desired effect. However, the String field in the coloring rule is yellow, and I'm also using the expression you explicitly cautioned against (tcp.flags.fin != 1). I got those flag expressions from the built-in "TCP SYN/FIN" coloring rule. What is the concern with that expression?
***
What would be really cool is if we could pass a variable to a filter expression, something like this:
frame.coloring_rule.name == "My Custom Color Rule:7"
and my color rule could be this:
tcp.stream eq $VAR$ && (!(tcp.flags & 0x02) || tcp.flags.fin != 1)
Then I could apply my custom coloring rule to any stream (#7 in my case) by passing a variable in the filter expression. I'd still like to have the coloring rules take precedence, or maybe provide that as an option in the Preferences.