Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] How can Wireshark improve

From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
Date: Fri, 25 Apr 2014 10:02:53 -0700
On Sat, Apr 19, 2014 at 12:48 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> On Apr 19, 2014, at 12:24 PM, Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote:
>
>> One think I would like to be able to do is "Show me all the SMB2
>> requests where the smb2.flags.is_response == true && smb2.nt_status !=
>> NT_STATUS_SUCCESS"
>
> Presumably you mean "show me all the SMB2 transactions (requests and matching responses) where the response returned an error".
>
> There's now a mechanism to, when saving filtered packets, save "related" packets.  I think this was introduced to allow the earlier fragments/segments of a reassembled packet to be saved, along with the final packet that matched the filter, but in at least some cases somebody might want to save the requests corresponding to replies that match the filter.
>
> 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.

+100

Way back I added special code to the nfs dissector so that certain
filter fields would match both the request and the response. A kludge.
But it would be really nice to have a way to flag control that a match
will also match all related packets. And have it work for all
request/response protocols.

>
> 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.

Yes.  I think in most cases you want to split packet relations up into
two buckets :
"packets are related because they form a request/reply (and or cancel) pair"
and
"packets are related for some other reason".

We could fix this by changing all request/response fields to a new
FT_REQUEST_REPONSE type.



> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe