Ahhh, I see ... icmp.resp_in is a flag set in ICMP Echo frames iff
Wireshark can find the associated Response
And icmp.resp_to is a flag set in ICMP Echo Reply frames iff Wireshark
can find the associated Request
That sounds like exactly what I want.
However.
(A)
"!(icmp.resp_in or icmp.resp_to) and (icmp.type==0 or icmp.type==8)"
shows me 2992 frames ... most of which seem to be perfectly good
request/response pairs
(B)
icmp.type==8 and !icmp.resp_in reports 1502 cases in which the Reply is
missing ... but on manual examination, the first three are not accurate.
(C) My Perl code finds 33 situations where a Request is missing from a
Reply or vice versa. On manual inspection, the first three are accurate
... I hope to crawl through the remainder, sanity checking them ...
If you'd like more detail, including the trace file:
https://vishnu.fhcrc.org/stuttered-icmp/
Wireshark 1.8.3 (SVN Rev 45256 from /trunk-1.8)
--sk
On 10/5/2012 9:08 AM, Martin Isaksson wrote:
Hi Stuart,
First I should say I am using Wureshark Version 1.8.2 (SVN Rev 44520 from /trunk-1.8).
I took an old capture file with ICMP pings, deleted one reply with frame.number != X and saved.
Then I used the filter below, and the only packet listed was the lone request.
icmp.resp_in seems only to be present in frames that Wireshark can find the response to.
The same for icmp.resp_to in the replies.
!(icmp.resp_in or icmp.resp_to) should be equivalent. The filter suggested by Gerald works for me as well, and I like it more than mine :)
Kind regards,
Martin