Hi Merton,
Does this display filter help you:
(icmp.type == 3) || (icmp.type == 4)
ICMP Destination Unreachable: type = 3
Source Quench: Type = 4
Regards
Joan
On Sat, 30 May 2009 10:47:39 -0700 Merton Campbell Crockett wrote:
>On 30 May 2009, at 09:54:50, Stephen Fisher wrote:
>
>> On Sat, May 30, 2009 at 09:24:22AM -0700, Merton Campbell Crockett
>> wrote:
>>
>>> In addition to looking at traffic to or from specific clients, I want
>>> to look at any ICMP traffic that involves the specific client. I've
>>> used the following filter expression.
>>>
>>> icmp or ip.addr eq 10.10.208.211
>>>
>>> Unfortunately, this filter includes all ICMP traffic instead of just
>>> the ICMP traffic that is related to 10.10.208.211.
>>
>> Try "icmp and ip.addr eq 10.10.208.211" to find packets to/from that
>> IP
>> that are ICMP -and- packets that have ICMP packets containing traffic
>> to/from that IP in the ICMP payload.
>
>Wouldn't the "icmp and ip.addr eq 10.10.208.211" expression result in
>only ICMP packets originating from or destined to 10.10.208.211 being
>displayed?
>
>All that I would expect to be displayed given the above expression are
>ICMP Source Quench and ICMP Port Unreachable packets sent by the
>client or the server.
>
>What I'm really interested in seeing is how the server or client
>behaves when a network device in the path between them interjects an
>ICMP packet. The problem that is being investigated only occurs with
>clients that connect to the server over a WAN. Clients connecting to
>the server over a LAN do not experience the problem.
>
>I can exclude network devices that wouldn't be in the path between the
>client and the server by appending an expression similar to the
>following to my original expression.
>
> and !(ip.addr eq 10.73.2.2 or ip.addr eq 10.10.1.3)
>
>Doing this, however, hides problems that might have been triggered by
>a routing flap.
>
>Thanks, I guess I didn't miss something in the Wireshark
>documentation. :-(
>
>
>Merton Campbell Crockett
>m.c.crockett@xxxxxxxxxxxxxx
