How to check return packet contents in ICMP Ping / Echo?

Question

When validating ping echo's, it seems that utilities / libraries often only check the checksum of the packet, and don't actually confirm that the payload sent out matches the payload that was returned. For instance, Wireshark's ICMP parser only checks for bad checksums, and that's all that Ruby's net-ruby checks as well.

I'm debugging a low-level network driver issue, and I need to confirm that the data isn't being mangled when received, so I want to test my driver using a low-level request such as ICMP Echo. However, my existing Ping tools are insufficient, because I fear that while the checksum may match the data contained in the echo response, the data in the echo response doesn't match the data in the echo request. So even though they both have valid checksums (there's no error in the checksum code), there's an error in the data receive portion, such that my driver isn't receiving what the host thinks it's sending out.

How might I check the echo payload to confirm that it's the same as what I sent out? If there's a standalone "paranoid ping" utility that I could use, that's fine too -- I just need to be able to vary the ping lengths and frequencies as I'm only seeing the problem when the network's flooded.

I'd prefer it in the form of a Ruby library / snippet, but any language or standalone app is acceptable, in so long as I can shoehorn it into running on Windows.

Thanks!

Answer 1

I think you're missing the point of the checksum. The purpose of the checksum is to validate that the data is intact. The sender calculates the checksum from the data and transmits it with the data. The receiver re-calculates a checksum from the data and compares it to the one that was sent. If they don't match, then the data isn't intact or one of the two is calculating it wrong. Most often bad checksums don't result in dropped packets because there's lots of broken protocol stacks out there, and of course packet manglers and that don't fix up the checksum, but if both sides do happen to do it properly then the checksum check tells you that the data is intact.

Are you looking at the TCP checksum or the ICMP checksum? The ICMP checksum doesn't include the TCP headers, only the ICMP type, code, checksum and data fields. A TCP checksum failure doesn't necessarily mean the ICMP contents aren't intact, it could just mean that the TCP headers were messed with (by a broken NAT, perhaps).

Answer 2

@Tom: Thanks for the answer. You said:

The receiver re-calculates a checksum from the data and compares it to the one that was sent.

But then you also said:

The ICMP checksum doesn't include the TCP headers, only the ICMP type, code, checksum and data fields.

The ICMP type is different between the echo request / response (one is 0, the other is I think 8). So by definition (and in practice, if you take a peek with Wireshark) the ICMP checksums don't match between the send request and the echo response.

My problem was that if ping utilities / libraries checked anything (and often they didn't), they only checked to make sure that the checksum matched the data. It seems that only rarely do people actually check the sent data with the echo'd response to make sure that the two payloads are identical. It's possible that both a request and a response could have valid checksums, but different payloads, and most Ping routines I've seen haven't checked for such a condition (but it happens to be the sort of bug I'm having on my device at the moment).

Thanks for looking at my question and responding though -- it is much appreciated.

@All:

In answer to my own question, I was able to use the robust .Net Ping class, as it gives me ready access to the received response buffer (unlike most other Ping libraries I found).