On Apr 19, 2014, at 3:48 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> So perhaps there should be a way to have a display filter show related packets in addition to packets that match the packet-matching expression.
>
> However, there are multiple flavors of "related", and sometimes you might want the corresponding requests but *not* other fragments/segments, and other times you might want the other fragments/segments but *not* the corresponding requests, and sometimes you might want both.
I had tried implementing a feature to show "related" packets, in a work-in-progress code change I abandoned a couple weeks ago:
https://code.wireshark.org/review/#/c/874/
It was done with a hack, but the basic problem with it was that the concept of "related" was too ambiguous and grabs too much. I put this in the abandon comment:
<comment>
This doesn't work right in certain cases. For example if you set a display filter for a sip request, you'll also get all the RTP packets because they're related, whereas you likely only wanted the related SIP messages.
I think what needs to happen instead is the user has to set two filters in one: a base one to narrow the scope, and then the real one to which related packets will be matched. For example "sip && related{ sip.response == 200 }", or something like that. Maybe "sip => sip.response == 200".
</comment>
-hadriel
