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
