Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-users: Re: [Wireshark-users] Filtering ICMP Packets Based on IP Addresses in the ICMP P

From: Merton Campbell Crockett <m.c.crockett@xxxxxxxxxxxxxx>
Date: Sat, 30 May 2009 10:47:39 -0700

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