Re: [Wireshark-dev] How can Wireshark improve
On Sat, Apr 19, 2014 at 12:48 PM, Guy Harris g...@alum.mit.edu wrote: On Apr 19, 2014, at 12:24 PM, Richard Sharpe realrichardsha...@gmail.com 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@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 ___ 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
Re: [Wireshark-dev] How can Wireshark improve
On 4/25/14 10:02 AM, ronnie sahlberg 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. This would let the Qt related packet delegate draw its indicators a bit more intelligently. ___ 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
Re: [Wireshark-dev] How can Wireshark improve
On Apr 25, 2014, at 10:02 AM, ronnie sahlberg ronniesahlb...@gmail.com 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.
___
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
Re: [Wireshark-dev] How can Wireshark improve
On 04/25/14 15:36, Guy Harris wrote:
On Apr 25, 2014, at 10:02 AM, ronnie sahlberg ronniesahlb...@gmail.com 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).
___
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
Re: [Wireshark-dev] How can Wireshark improve
On 04/22/2014 05:15 PM, Jeff Morriss wrote: I really, really, *really* should take some time to clean up the wiki documentation of MATE and provide a lot more examples... Somehow I never find the motivation to tackle that beast... On a side note, should we aim for getting this stuff in the Users Guide anyway? Thanks, Jaap ___ 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
Re: [Wireshark-dev] How can Wireshark improve
On Thu, Apr 24, 2014 at 10:12 PM, Jaap Keuter jaap.keu...@xs4all.nl wrote: On 04/22/2014 05:15 PM, Jeff Morriss wrote: I really, really, *really* should take some time to clean up the wiki documentation of MATE and provide a lot more examples... Somehow I never find the motivation to tackle that beast... On a side note, should we aim for getting this stuff in the Users Guide anyway? I dunno, but I find my self dealing with larger and larger captures, and multiple captures (taken from multiple systems at the same time) where I have to try to relate one capture to another ... I really need more support to analyse them. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ 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
Re: [Wireshark-dev] How can Wireshark improve
On 04/19/14 15:48, Guy Harris wrote: On Apr 19, 2014, at 12:24 PM, Richard Sharpe realrichardsha...@gmail.com 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. Which, technically, you should be able to do today. The problem is you'd have to use MATE to do it and that's really a pain. Quick thoughts on how to do it with MATE: - Create a PDU for SMB messages - Create a Gop named smb_transaction which contains request and the corresponding answer PDUs (I suppose there's some parameter in SMB that allows you to correlate the two); store the nt_status in here (with the Extra key word) - Use a display filter like smb2.flags.is_response == false mate.smb_transaction.nt_status != NT_STATUS_SUCCESS I really, really, *really* should take some time to clean up the wiki documentation of MATE and provide a lot more examples... Somehow I never find the motivation to tackle that beast... ___ 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
Re: [Wireshark-dev] How can Wireshark improve
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
Re: [Wireshark-dev] How can Wireshark improve
On Sat, Apr 19, 2014 at 12:48 PM, Guy Harris g...@alum.mit.edu wrote: On Apr 19, 2014, at 12:24 PM, Richard Sharpe realrichardsha...@gmail.com 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. Yes, although that was just an example. In other cases I would like to see all the SMB Creates where the requested access == 0x120196 or whatever ... 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. Yeah, but then I want to be able to step through each of the packets found and look at the one before or after, so I am continually hitting clear and apply and so fort. It gets to be a pain, so then I thought of the concept of having a search results pane that when you click on one of the search results syncs the main pane so you can move around and inspect more etc. -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___ 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
Re: [Wireshark-dev] How can Wireshark improve
On Apr 19, 2014, at 12:24 PM, Richard Sharpe realrichardsha...@gmail.com 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. 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. ___ 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
