Hi Ronnie,
Success
wireshark-1.9.0-SVN-45378 plus 'not (icmp.resp_in or icmp.resp_to) and
not ntp and not arp' delivers 33 frames
my Perl script reports 33 frames
And visual inspection of the first handful show the same frames.
Thank you,
--sk
On 10/6/2012 8:54 AM, ronnie sahlberg wrote:
Stuart,
can you try building the latest svn of wireshark?
I have fixed up icmp request/response processing so it should be better now.
regards
ronnie sahlberg
On Fri, Oct 5, 2012 at 9:46 AM, ronnie sahlberg
<ronniesahlberg@xxxxxxxxx> wrote:
The problem is that the request/response matching for ICMP is a bit too simple.
It assumes that there is not that many icmp messages so it ignores
the case where you have
a situation where the seuqnmce number is repeated at a later time.
For example , see this filter :
icmp.seq == 56578
First pair 110/111 are notr matched but the final pair 11678/11679 is.
I think wireshark itnernally only keeps one single record for the icmp
sequence number, so when it is reused in later transactions the
final transaction "wins"
This could be semi-easy to fix by making the request/response matching
a bit more intelligent and allow a icmp sequence number to be re-used
and to be able to keep track of multiple transactions all with the
same transaction number.
I can have a look at fixing this sometime during the weekend unless
someone else beats me to it.
regards
ronnie sahlberg
On Fri, Oct 5, 2012 at 9:33 AM, Stuart Kendrick <skendric@xxxxxxxxx> wrote:
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
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
