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: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Fri, 25 Apr 2014 17:02:53 -0400
On 04/25/14 15:36, Guy Harris wrote:

On Apr 25, 2014, at 10:02 AM, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:

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.

"Request/response fields" in the sense of "fields used to match requests and responses" (such as ONC RPC XIDs), or "request/response fields" in the sense of "for a {request,response}, the frame number of the corresponding {response,request}"?  If the latter, presumably you mean using FT_REQUEST_RESPONSE (or perhaps FT_MATCHING_REQUEST and FT_MATCHING_RESPONSE) rather than FT_FRAMENUM.

Obviously (I think) we wouldn't want to copy all the fields from the request to the response and vice-versa.

And I'm not sure we'd want the dissector writer to choose which are the fields from the request which might be of interest in the response and vice-versa; besides, it would probably take a lot of effort to manually change all those fields. The nice thing in MATE is I (the MATE script writer) can choose what field I want from the request and what I want from the response.

Using the idea of FT_MATCHING_REQUEST and FT_MATCHING_RESPONSE, should the display filter syntax allow for something like (going back to Guy's translation of Richard's request):

response(smb2.nt_status) != NT_STATUS_SUCCESS || smb2.nt_status != NT_STATUS_SUCCESS

The "response()" function tells Wireshark to fetch the argument field from the response of the current frame (if any). The stuff after the "||" is necessary to also display the response itself (you might not always care to see the response).

Of course this would have an interesting effect: while deciding if frame 42 matches the dfilter Wireshark would have to go off and dissect frame 142 (the response).