But the entire encapsulated IP header is present, correct? So it should be possible to verify the encapsulated IP header checksum, shouldn't it?
In the bug report I filed, the IP header was correctly identified as incorrect because it was. But the key there was that it could be correctly verified since the encapsulated IP header was present; therefore disallowing that verification was the wrong thing to do, as Stig realized and backed out the patch. If I'm still not understanding correctly, for my own benefit, maybe you could post a small capture file depicting the situation? - Chris -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stephen Fisher Sent: Monday, March 14, 2011 4:59 PM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 36193: /trunk/epan/dissectors/ /trunk/epan/dissectors/: packet-icmp.c Chris, Thanks for pointing that out - I had forgotten about that bug report. The case I'm looking at is where an ICMP echo request goes out with an ICMP header of 8 bytes + a payload of 32 bytes for a ping. Then I receive an ICMP destination host unreachable containing the original IP header and ICMP header but *not* the 32 byte payload from the original ICMP echo request. My understanding is that this lack of echo request's payload (per RFC #792 - "Internet Header + 64 bits of Original Data Datagram") causes the ICMP echo request to no longer be verifiable. I have both the original and returned packets and the IP total length is 60 bytes in both cases, unlike in the bug report you had made. [The intended recipient of this message is anyone and everyone.] CONFIDENTIALITY NOTICE: The contents of this email are confidential and for the exclusive use of the intended recipient. If you receive this email in error, please delete it from your system immediately and notify us either by email, telephone or fax. You should not copy, forward, or otherwise disclose the content of the email. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
