Response In/To in a icmp packets

Question

Hello,

I used wireshark to resolv a problem! pings goes lost sometimes on my network...

I've see following packets on wireshark and I need to known is this normal or not! For one ping the are four packet, two with request and two with reply ( I means so because the four packets are same sequence number ): 393 53.000650 192.168.141.100 10.151.56.99 ICMP 98 Echo (ping) request id=0x8132, seq=1008/61443, ttl=53 394 53.000720 192.168.141.100 10.151.56.99 ICMP 98 Echo (ping) request id=0x8132, seq=1008/61443, ttl=53 395 53.000782 10.151.56.99 192.168.141.100 ICMP 98 Echo (ping) reply id=0x8132, seq=1008/61443, ttl=64 396 53.000808 10.151.56.99 192.168.141.100 ICMP 98 Echo (ping) reply id=0x8132, seq=1008/61443, ttl=64

BUT the following is strange for me : Only two packets have [Response In: <number>] in the ICMP header like : Internet Control Message Protocol Type: 8 Code: 0 ... [Response In: 395] and Internet Control Message Protocol Type: 0 Code: 0 ... [Response To: 394] [Response Time: 0.062 ms]

The two other packets (393 request / 396 reply) don't have this [Response To/In].

It's means a problem ? Could please someone help me?

Thanks in advance

Accepted Answer

1

It just means that Wireshark was only able to match one request to a reply, and is not a problem, at least not one of your network.

One can argue if Wireshark should be able to match the other two packets as well. But I suspect you have duplicates in your trace, meaning that there was only one request and one reply you recorded twice. That's probably a result of your capture method, for example if you span/mirror more than one port (usually both target and destination ports, and both of them ingress AND egress). And if there's a duplicate Wireshark will only match the ping packets once, because it will probably keep the last echo request id in mind until it finds a reply.

answered 20 Mar '12, 04:06

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

Thanks for your answer! So, I've redirect a specific vlan (virtual interface from switch) into a interface where my laptop with wireshark was plugged. The capture method was by default whitout change anything! Perhaps my traces are duplicated? do you really means that's not a problem?

(20 Mar '12, 06:53) nymus7

I guessed as much - redirecting a VLAN will result in duplicates if two nodes send messages to each other, because both the node sending and the node receiving will lead to a copy of the packet in the trace. So not your whole trace is duplicated, but just the packets of nodes talking to each other within the VLAN you redirected.

(20 Mar '12, 06:58) Jasper ♦♦

So, first of all, the "Response To/In" issue is not a problem. The duplicates are a problem, because for TCP communications you might see tons of retransmissions when they're just duplicates. You should use editcap -d <yourcapturefile> <deduplicatedfile> to deduplicate your trace before analysis (editcap comes with Wireshark and is a command line tool).

(20 Mar '12, 07:00) Jasper ♦♦

@nymus7, can you post a capture file to wireshark-dev with the 4 ICMP packets in it? It may be possible to modify the ICMP conversation handling to better account for duplicates.

(20 Mar '12, 07:45) cmaynard ♦♦

Chris, I wouldn't put too much work into it, otherwise you'll have to handle all the other sideeffects of duplicate packets as well... retransmissions etc, tons of work ;-)

Without having looked at the code I guess the ICMP dissector is "dragging" a variable with the last echo request identifier for that IP pair along and tries to match it with a reply. Which is why in a duplicated packet the second will be kept and matched while the first is lost. To extend that for multiple instances of the same duplicate packet will be no fun and too complicated - let people dedupe their traces instead ;-)

(20 Mar '12, 07:54) Jasper ♦♦

Ok! this is the trames : No. Time Source Destination Protocol Length Info 434 59.000605 192.168.141.100 10.151.56.99 ICMP 98 Echo (ping) request id=0x8132, seq=1014/62979, ttl=53

Frame 434: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Arrival Time: Mar 19, 2012 14:35:23.463877000 Mitteleuropäische Zeit Epoch Time: 1332164123.463877000 seconds [Time delta from previous captured frame: 0.961062000 seconds] [Time delta from previous displayed frame: 0.961062000 seconds] [Time since reference or first frame: 59.000605000 seconds] Frame Number: 434 Frame Length: 98 bytes (784 bits) Capture Length: 98 bytes (784 bits) [Frame is marked: True] [Frame is ignored: False] [Protocols in frame: eth:ip:icmp:data] [Coloring Rule Name: ICMP] [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: Cisco_08:e3:43 (f0:f7:55:08:e3:43), Dst: Vmware_a6:57:e5 (00:50:56:a6:57:e5) Internet Protocol Version 4, Src: 192.168.141.100 (192.168.141.100), Dst: 10.151.56.99 (10.151.56.99) Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 Checksum: 0x6bbc [correct] Identifier (BE): 33074 (0x8132) Identifier (LE): 12929 (0x3281) Sequence number (BE): 1014 (0x03f6) Sequence number (LE): 62979 (0xf603) Data (56 bytes)

0000 1b 36 67 4f 00 00 00 00 bb c2 0a 00 00 00 00 00 .6gO............ 0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()+,-./ 0030 30 31 32 33 34 35 36 37 01234567 Data: 1b36674f00000000bbc20a00000000001011121314151617... [Length: 56]

No. Time Source Destination Protocol Length Info 435 59.000658 192.168.141.100 10.151.56.99 ICMP 98 Echo (ping) request id=0x8132, seq=1014/62979, ttl=53

Frame 435: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Arrival Time: Mar 19, 2012 14:35:23.463930000 Mitteleuropäische Zeit Epoch Time: 1332164123.463930000 seconds [Time delta from previous captured frame: 0.000053000 seconds] [Time delta from previous displayed frame: 0.000053000 seconds] [Time since reference or first frame: 59.000658000 seconds] Frame Number: 435 Frame Length: 98 bytes (784 bits) Capture Length: 98 bytes (784 bits) [Frame is marked: True] [Frame is ignored: False] [Protocols in frame: eth:ip:icmp:data] [Coloring Rule Name: ICMP] [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: Cisco_08:e3:43 (f0:f7:55:08:e3:43), Dst: Vmware_a6:57:e5 (00:50:56:a6:57:e5) Internet Protocol Version 4, Src: 192.168.141.100 (192.168.141.100), Dst: 10.151.56.99 (10.151.56.99) Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 Checksum: 0x6bbc [correct] Identifier (BE): 33074 (0x8132) Identifier (LE): 12929 (0x3281) Sequence number (BE): 1014 (0x03f6) Sequence number (LE): 62979 (0xf603) [Response In: 436] Data (56 bytes)

0000 1b 36 67 4f 00 00 00 00 bb c2 0a 00 00 00 00 00 .6gO............ 0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()+,-./ 0030 30 31 32 33 34 35 36 37 01234567 Data: 1b36674f00000000bbc20a00000000001011121314151617... [Length: 56]

No. Time Source Destination Protocol Length Info 436 59.000715 10.151.56.99 192.168.141.100 ICMP 98 Echo (ping) reply id=0x8132, seq=1014/62979, ttl=64

Frame 436: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Arrival Time: Mar 19, 2012 14:35:23.463987000 Mitteleuropäische Zeit Epoch Time: 1332164123.463987000 seconds [Time delta from previous captured frame: 0.000057000 seconds] [Time delta from previous displayed frame: 0.000057000 seconds] [Time since reference or first frame: 59.000715000 seconds] Frame Number: 436 Frame Length: 98 bytes (784 bits) Capture Length: 98 bytes (784 bits) [Frame is marked: True] [Frame is ignored: False] [Protocols in frame: eth:ip:icmp:data] [Coloring Rule Name: ICMP] [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: Vmware_a6:57:e5 (00:50:56:a6:57:e5), Dst: All-HSRP-routers_01 (00:00:0c:07:ac:01) Internet Protocol Version 4, Src: 10.151.56.99 (10.151.56.99), Dst: 192.168.141.100 (192.168.141.100) Internet Control Message Protocol Type: 0 (Echo (ping) reply) Code: 0 Checksum: 0x73bc [correct] Identifier (BE): 33074 (0x8132) Identifier (LE): 12929 (0x3281) Sequence number (BE): 1014 (0x03f6) Sequence number (LE): 62979 (0xf603) [Response To: 435] [Response Time: 0.057 ms] Data (56 bytes)

0000 1b 36 67 4f 00 00 00 00 bb c2 0a 00 00 00 00 00 .6gO............ 0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()+,-./ 0030 30 31 32 33 34 35 36 37 01234567 Data: 1b36674f00000000bbc20a00000000001011121314151617... [Length: 56]

No. Time Source Destination Protocol Length Info 437 59.000739 10.151.56.99 192.168.141.100 ICMP 98 Echo (ping) reply id=0x8132, seq=1014/62979, ttl=64

Frame 437: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) Arrival Time: Mar 19, 2012 14:35:23.464011000 Mitteleuropäische Zeit Epoch Time: 1332164123.464011000 seconds [Time delta from previous captured frame: 0.000024000 seconds] [Time delta from previous displayed frame: 0.000024000 seconds] [Time since reference or first frame: 59.000739000 seconds] Frame Number: 437 Frame Length: 98 bytes (784 bits) Capture Length: 98 bytes (784 bits) [Frame is marked: True] [Frame is ignored: False] [Protocols in frame: eth:ip:icmp:data] [Coloring Rule Name: ICMP] [Coloring Rule String: icmp || icmpv6] Ethernet II, Src: Vmware_a6:57:e5 (00:50:56:a6:57:e5), Dst: All-HSRP-routers_01 (00:00:0c:07:ac:01) Internet Protocol Version 4, Src: 10.151.56.99 (10.151.56.99), Dst: 192.168.141.100 (192.168.141.100) Internet Control Message Protocol Type: 0 (Echo (ping) reply) Code: 0 Checksum: 0x73bc [correct] Identifier (BE): 33074 (0x8132) Identifier (LE): 12929 (0x3281) Sequence number (BE): 1014 (0x03f6) Sequence number (LE): 62979 (0xf603) Data (56 bytes)

0000 1b 36 67 4f 00 00 00 00 bb c2 0a 00 00 00 00 00 .6gO............ 0010 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f ................ 0020 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f !"#$%&'()+,-./ 0030 30 31 32 33 34 35 36 37 01234567 Data: 1b36674f00000000bbc20a00000000001011121314151617... [Length: 56]

All the ICMP frames look like this four!

Thank you very much for your help!

(20 Mar '12, 08:10) nymus7

@Jasper, +1 for not putting effort in making dissectors handle duplicate packets. If at all handling duplicates, make the frame dissector mark them as a duplicate to prevent them from being processed by upper layer dissectors.

@Jasper, when you span a vlan (both TX and RX) you will always get duplicates, even if one system is outside the vlan. The packet has to leave the vlan towards the routing engine, so it egresses the vlan in that scenario too. Although IIRC, I have seen switches not duplicate them in that case. Oh well... I always use RX only and check whether I get both flows!

(20 Mar '12, 11:15) SYN-bit ♦♦

I wanted to see if the packets were truly duplicates or if there might be something to distinguish them. When I added the ICMP conversation tracking, I had performed some testing with capturing on the "any" interface and found problems when GRE tunnels were involved because I would see both the pre- and post-encapsulated ICMP echo request/reply packets. In that case, I was able to modify things slightly in order to distinguish between them. But in this case, it looks like the packets are truly duplicates, so de-duping is the way to go.

(20 Mar '12, 13:43) cmaynard ♦♦

Thanks for your help!

@cmaynard Ok, if you means that these packets truly duplicate and I must to de-duping this one, should I use this command: editcap -d "yourcapturefile" "duplicatedfile" to do that? My question is which file is the "deduplicatedfile" ? because I've only one : "yourcapturefile"

(21 Mar '12, 01:23) nymus7

@nymus7

I've converted your "answer" to a comment as that's how this site works, see the FAQ.

If any answers solve your problem, plese accept them by clicking the "check" symbol.

(21 Mar '12, 03:24) grahamb ♦

@nymus7: the "deduplicatedfile" is the output of the deduplication process. You throw your existing file (with duplicates) into editcap and let it write a new, deduplicated file. It's like a copy process, but with leaving out the duplicates.

(21 Mar '12, 04:26) Jasper ♦♦

@jasper: It doesn't seen any packet! So, perhaps it is a another problem...

C:\Program Files\Wireshark>editcap.exe -d d:\TROUBLESHOOTING\VLAN56.pcap -v
0 packets seen, 0 packets skipped with duplicate window of 5 packets.
C:\Program Files\Wireshark>editcap.exe -D 10000 d:\TROUBLESHOOTING\VLAN56.pcap
0 packets seen, 0 packets skipped with duplicate window of 10000 packets.

(21 Mar '12, 07:06) nymus7

Is it possible that you upload a trace with just the four ICMP packets to Cloudshark at http://www.cloudshark.org/, and post the link here? So we can take a look at it and see what happens. It's better than posting ASCII exports. You can use the "Save As" function in Wireshark to save only parts of the file, for example by first marking the relevant frames.

(21 Mar '12, 07:19) Jasper ♦♦

Nice tool! Ok, here's the link : ICMP_VLAN56

Thanks a lot for your help....

(21 Mar '12, 07:42) nymus7

Here's what happens if I run editcap -d on the exerpt:

[D:\]editcap -d ICMP_VLAN56.pcap deduplicatedfile.pcap 4 packets seen, 2 packets skipped with duplicate window of 5 packets.

Maybe in your original file they're too far apart to be found by the default parameters, which compares the last 5 frames. Try working with the additional -D parameter to increase the search range. I'd go for -D 20 for starters, or maybe -D 50, that should be enough.

editcap -d -D 20 yourcapturefile.pcap deduplicatedfile.pcap

(21 Mar '12, 08:27) Jasper ♦♦

Now it's work! Thanks a lot for your help...

It was really duplicated's frames!

(21 Mar '12, 08:45) nymus7

@nymus7

Yet again I've converted your "answers" to a comment, please don't post comments as answers and read the FAQ.

As your question now seems to have been solved please accept the answer.

(21 Mar '12, 08:54) grahamb ♦

Ok, I've read the FAQ and yes, my questions have been solved! Thanks a lot!

(22 Mar '12, 00:45) nymus7

showing 5 of 18 show 13 more comments