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

Why I cant ping device using router : what cause the checksum error?

This IDU device can be ping by PC but cannot be ping using router

Result of wireshark trace.

Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0xca7c [incorrect, should be 0xac40]
Identifier (BE): 72 (0x0048)
Identifier (LE): 18432 (0x4800)
Sequence number (BE): 0 (0x0000)
Sequence number (LE): 0 (0x0000)
Data (92 bytes)
  Data: 000000000000000000000000000000000000000030313233...
  Length: 92

Hope someone can answer

thanks guys

icmp snmpwireshark

asked 25 Jul '16, 20:20

champy
6●1●1●3
accept rate: 0%

edited 25 Jul '16, 22:40

sindy
6.0k●4●8●51

Not without proper trace files (instead of a single text line) of both the working and not working situations. Can you share a capture in a publicly accessible spot, e.g. CloudShark?

(25 Jul '16, 22:26) Jaap ♦

Hi @jaap thanks for the comment.

Here's the link for the trace

https://www.cloudshark.org/captures/7d2ac6e985ac

thank you

(25 Jul '16, 22:56) champy

Where was that capture taken? On a device (what IP?) or with a dedicated PC/laptop?

(26 Jul '16, 01:52) Jasper ♦♦

Hi,

Sorry for incomplete details.

Data capture using a laptop (no IP address) from a switch using Port mirroring.

192.168.237.251 is the device that cannot be ping using router

192.168.237.1 is the router that pings the IDU device.

thank you

(26 Jul '16, 01:58) champy

What is missing in the capture is the icmp exchange in the working situation for which @Jaap has asked.

As the IP header checksums are OK, the data contents is the same between requests and responses, and the Ethernet FCSs were likely OK as well because otherwise your network card would have dropped the frames, it seems that the IDU's IP stack has an issue with calculation of the ICMP checksum.

It is possible that the PC which "has no problem" with the IDU's responses actually doesn't care about the ICMP checksum or that the IDU calculates it correctly when it responds to the requests coming from the PC, possibly due to different data contents in the requests coming from the PC and the requests coming from the router.

(26 Jul '16, 04:25) sindy

Hi @Sindy, thanks for the reply. Is there other way to resolved this issue?

can you please compare the results for the router and PC data when it pings the IDU? Can you also put it here so you can teach me how to read it, please.

here's the wireshark trace PC pings the IDU https://www.cloudshark.org/captures/3ff0457472d1

PC - 192.168.237.250

I really appreciate your help.

Many thanks.

(26 Jul '16, 19:00) champy

The first thing to bear in mind is that Wireshark shows you what has happened but rarely why it has happened. Even when Wireshark suggests a particular error/malfunction, you have to consider it in context.

In this case, the facts which Wireshark shows you directly are:

that the checksum of the ICMP echo responses to requests sent by the router is wrong,
that the checksum of the ICMP echo responses to requests sent by the PC is correct,

The facts which Wireshark shows you indirectly are:

that the correct difference between a checksum of an ICMP echo request message and its matching ICMP echo response message is 0x800 (which is due to the method how the checksum is computed and due to the only difference between these two messages, which is the Type field, which is 0 in case of response and 8 in case of request)
that the ICMP parts of matching echo requests and echo responses from/to the router do not differ in any other bytes than the Type field and the checksum.

But Wireshark can not show you why exactly the checksum of the response is wrong because the possible reasons are so many that it is impossible to anticipate all these possibilities and verify them one by one.

In such cases, your further steps are usually determined by the amount of control you have over the suspectedly faulty protocol implementation. If you can, you identify the bug in the code and fix it; if you cannot, you look for a workaround, allowing you to use the implementation without getting affected by the bug.

(27 Jul '16, 00:08) sindy

So let's look at possible reasons why the IDU calculates the checksum incorrectly for responses to requests coming from the router. If the reason is logical, it must be one of the differences between the echo request packets from the PC and those from the router.

These differences are the following:

the size of the data part
the contents of the data part (the one from the router contains many zero bytes which is not illegal but the IDU may handle it improperly)
the zero value of sequence as coming from the router (which is not illegal but the IDU may handle it improperly)

So as the first step (because it is the simplest one and can be used as workaround straight away), I would use -l parameter to the ping to specify 32 bytes of packet data when pinging from the router, and 92 bytes of packet data when pinging from the PC.

Next, I would try to affect the data contents, which may not be easy as you might need to create your own icmp packets, stock pings usually do not provide such option. Assuming that you cannot install a "make your own packet" software nor any fancy ping on the router, the only outcome I can imagine is that you confirm that the zero bytes in the data cause the issue by sending them from the PC. I.e. the result would not be usable as a workaround, only as a hint for fixing the IDU's ICMP stack.

Same as above applies for the sequence number.

(27 Jul '16, 00:36) sindy

showing 5 of 8 show 3 more comments