This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Strange ICMP packets…

0

A colleague of mine has sent me this strange PCAP file. He has taken a PCAP file on a core switch and capture the ping packets from my PC to a remote device. The first ICMP echo msg gets an echo reply. But then a third echo request is sent (without any reply found in the trace). Take a look at the negative timing of this packet... This schema does repeat indefinitely.

Any idea about the potential cause of this strange behaviour ?alt text

asked 14 Oct '16, 07:57

thierryn's gravatar image

thierryn
219912
accept rate: 0%


One Answer:

2

I suspect packet three is a duplicate of packet 1. Notice the TTL: packet 1 is decremented (127 instead of 128). What is the span or mirror port setup? I would suspect two source ports into a single destination.

I can replicate something very close, except for the specific timing. With a poorly(*) configured port mirror or span setup on my switch/router, I can end up with the same as you have:

alt text

The ttl change is telling in that you crossed a router so it is not likely a layer2 loop or anything like that; the specific configuration for this is to configure a router with mirror port capability and then:

  1. Copy ingress of incoming ICMP request from the source, so in my case port connected to 192.168.1.14 (/24). So we see an ICMP request with full TTL. We would not see any response because we limited to ingress. Frame 4.
  2. Copy BOTH ingress and egress of ICMP response, so port connected to 192.168.3.178. We will see the ICMP request as it leaves the router so ttl is decremented, and then the response with full ttl as we see it before routing. We see both because we have ingress and egress set. Frames 5 and 6.
  3. Destination mirror for this test was the same port for both of these links

There are probably other ways to get this. The timing is dependent on a lot of things. I have seen Cisco span ports mirror packets out of order (obvious to see when it happens with TCP). This diagnostic feature is usually lower priority than other device functions, so you never really know how that will affect the timing. What happens when we mirror two 1GB ports into a single 1GB destination? Not good things...

Also the negative timestamp is common for me when I capture on two separate interfaces at the same time. Instead of setting the mirror destination to the same port as in point 3 above, use separate destinations but capture on the same PC, with two NICs. Make one of the them a USB NIC and heavily load the system. Timing could be a mess.

*My assertion that this is poor is true for me - I have no need to configure my span ports in this manner for my daily work. However, it may be perfectly valid for whatever it is you are trying to do. For understanding ICMP echo flows across a router this is probably not the best choice.

answered 14 Oct '16, 10:06

Bob%20Jones's gravatar image

Bob Jones
1.0k2515
accept rate: 21%

edited 15 Oct '16, 03:28

What can explain a TTL=127 for a duplicate packets ?

(14 Oct '16, 23:15) thierryn

Your answer has been converted to a comment as that's how this site works. Please read the FAQ for more information.

(15 Oct '16, 00:19) Jaap ♦

I would assume, somehow a router is influencing it's TTL. Awkward indeed.

(18 Oct '16, 02:38) SynAck

What can explain a TTL=127 for a duplicate packets ?

As @Bob Jones has already explained - the same "logical packet" is captured twice, before and after passing through a router.

  • each pass through a router decrements packet's TTL to prevent packets to loop through the network forever if routing errors create a loop. This explains why the two copies of the packet have a TTL differing by 1,

  • the mirroring mechanism in the switch may not deliver frames grabbed at different sources in the same order in which they passed the source ports. This would explain why a packet with lower TTL was captured before a packet with higher TTL, but not why there is a negative timestamp delta between them, because the timestamps are assigned by the capturing machine, not the mirroring switch,

  • this leads to suspicion that the capture has been taken at several interfaces simultaneously and their timestamper-to-file propagation times were different (so the packet with earlier timestamp was written to the file later than the one with later timestamp) or that the capture file has been merged from two source files captured on different machines with slightly offset real time clock.

(18 Oct '16, 03:00) sindy