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