Wireshark-users: Re: [Wireshark-users] Filtering ICMP Packets Based on IP Addresses in the ICMP P
On 30 May 2009, at 12:17:54, j.snelders@xxxxxxxxxx wrote:
Does this display filter help you:
(icmp.type == 3) || (icmp.type == 4)
ICMP Destination Unreachable: type = 3
Source Quench: Type = 4
Not really. Perhaps, it might be better for me to explain the problem
that is occurring and how I collected the network traffic.
First, the network traffic was collected using a Cisco Network
Analyzer Module (NAM) at the switch port connecting to the server. I
collected 1 GB of "raw" traffic data. By "raw", I mean that there
were absolutely no filters defined as I wanted to capture all packets
that traversed the network segment, i.e. I wanted to capture any
"broadcast storms" that might impact the operation of the server along
with any network traffic that was erroneously being routed/switched to
the segment.
Microsoft's Office Communicator 2005 and Live Communications Server
2005 are used to provide an instant messaging capability on our
corporate network. User's have complained that while IM'ing another
user that they will receive an error message stating that the message
that they just sent could not be delivered to one or more recipients.
Also, they report that a user in their contact list will suddenly
change from online to offline.
Management has gotten Microsoft involved in the problem. I have not
been impressed with the technicians that have been involved in the
problem. It was like pulling teeth to get them to explain how
"presence" was determined. They keep saying that it is a network
problem while not being able to explain how the network and the
Windows TCP/IP stack impacts the application.
At any rate, we have determined that the "online" to "offline" state
transition is being triggered by a TCP reset. In some instances,
there is an automatic reconnection occurring almost immediately. In
others, the user has to stop and start Office Communicator to restore
use.
I'm trying to determine what is triggering the TCP reset. Also, I'm
trying to determine under what conditions will the connection be
automatically restored.
Basically, I use a "tcp.flags.reset eq 1" filter to find Office
Communicator clients of interest. I then use the "icmp or ip.addr eq
wh.at.ev.er" filter to find all events associated with the client.
Unfortunately this includes all ICMP packets regardless of where they
originated hence my original question.
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
___________________________________________________________________________
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
Merton Campbell Crockett
m.c.crockett@xxxxxxxxxxxxxx
