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: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] 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.
