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