On Apr 19, 2014, at 3:48 PM, Guy Harris <g...@alum.mit.edu> 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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
