[Merton Campbell Crockett <m.c.crockett@xxxxxxxxxxxxxx>]

On 31 May 2009, at 02:43:30, Sake Blok wrote:

> In an earlier mail you said:
>
> "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."
>
> Combined with the fact that you see a TCP reset on the events that  
> you are investigating leads me to believe the problem lies in  
> devices that keep session state (firewalls, IDP, Loadbalancers,  
> etc). Every device that keeps session states has a mechanism to  
> flush old sessions, otherwise their table would grow forever.  
> Usually they clear out sessions that have been idle for certain  
> amount of time. Idle being that no network traffic has been seen for  
> that session (in some protocols the user may be idle, but network  
> traffic is still present for the session). Other devices use an  
> absolute timer for sessions (a mamimum time that a session may live,  
> even when it's active), however, I have not seen this much.
>
> If a session is flushed from the device and a new packet of that  
> session is sent by the client or the server, it will be discarded or  
> rejected and the intermediate device might send a reset. If it is  
> the server sending the reset, then somehow the session was dropped  
> on the server, instead of an intermediate device.


If the intermediate device function as a security device, the packet  
would most likely be discarded rather than rejected.  A rejected  
packet triggers a response back to the sender that potentially reveals  
something about the network behind the device.


> Now back to your original question, if you use the filter "icmp and  
> ip.addr==x.x.x.x", it will give you all packets originating from or  
> destined to x.x.x.x, but also all icmp packets in which the ip  
> header in the payload contains ip address x.x.x.x. There is however  
> no way to restric the filter to show *only* packets where x.x.x.x is  
> in the icmp payload.


I'm an old fart.  I have a tendency to write filtering expressions  
based on how the BSD Packet Filter works.  In that environment, an  
"or" would be required to capture the needed traffic.

The key point to remember is that the data was captured, essentially,  
at the server.  I was using the client's IP address as the selector  
for the traffic of interest.  The only ICMP traffic from the client  
that might have been captured would have been an ICMP Source Quench or  
ICMP Port Unreachable.

All other ICMP traffic would have been directed to the server.   
Obviously, I wouldn't want to use the server's IP address in my filter  
as it would include all of the traffic that was captured.  Adding ICMP  
to the expression was required to determine whether they were the  
trigger for some of the TCP reset packets that closed the virtual  
circuit between the client and the server.

The packet that triggered the ICMP response is included in the ICMP  
packet to allow the recipient to identify the virtual circuit having a  
problem.  Hence my original question about filtering ICMP traffic  
based on the IP packet in the payload.

I can use my knowledge of network topology to exclude some ICMP  
packets.  The problem with doing that is that you might miss a weird  
condition where traffic was being misrouted.


> I attached a small capture file in which this can be seen, use the  
> filter "icmp and ip.addr==194.134.5.5". The trace contains a  
> traceroute from 192.168.1.46 to 194.134.5.5.
>
> Hope this helps,
> Cheers,
>    Sake
>
>
> ----- Original Message ----- From: "Merton Campbell Crockett" <m.c.crockett@xxxxxxxxxxxxxx 
> >
> To: "Community support list for Wireshark" <wireshark-users@xxxxxxxxxxxxx 
> >
> Sent: Saturday, May 30, 2009 10:51 PM
> Subject: Re: [Wireshark-users] Filtering ICMP Packets Based onIP  
> Addresses in the ICMP Payload
>
>
> > 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
> >
> >
> >
> > ___________________________________________________________________________
> > 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
> < 
> icmp 
> .cap 
> > 
> ___________________________________________________________________________
> 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