 |
|
Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
|
|
Custom Search
|
|
ICMPv4 Parameter Problem Messages
(Page 1 of 2)
The previous topics in this section describe four specific ICMPv4 message types that allow a device to report various error conditions to the original sender of a datagram. However, other error situations may arise also that don't correspond to any of these four specific message types. Typically, the problem results when a device attempts to process the header fields of an IP datagram and finds something in it that doesn't make sense.
If a device finds a problem with any of the parameters in an IP datagram header that is serious enough that it cannot complete processing the header, it must discard the datagram. Like other cases where a datagram must be tossed out, this is serious enough to warrant communication of the problem back to the device that sent the original datagram. This is accomplished in ICMPv4 using the Parameter Problem message type.
This is a “catch all” type of message that can be used to indicate an error in any header field of an IP datagram. The message type does not contain any specific fields or coding to indicate what the problem is. This was done intentionally to keep the Parameter Problem message “generic” and ensure that it could indicate any sort of error. Instead of special error codes, most Parameter Problem messages tell the original source which parameter caused the problem by including a special pointer that indicates which field in the original datagram header caused the problem.
Table 94 and Figure 145 show the format for ICMPv4 Parameter Problem messages.
Field Name |
Size (bytes) |
Description |
Type |
1 |
Type: Identifies the ICMP message type; for Parameter Problem messages this value is 12. |
Code |
1 |
Code: Identifies the “subtype” of problem being communicated. See Table 95 for more information on this field for Parameter Problem messages. |
Checksum |
2 |
Checksum: 16-bit checksum field for the ICMP header, as described in the topic on the ICMP common message format. |
Pointer |
1 |
Pointer:
An offset that points to the byte location in the datagram that caused
the Parameter Problem message to be generated. The device receiving
the ICMP message can use this value to get an idea of which field in
the original message had the problem. |
Unused |
3 |
Unused: 3 bytes that are left blank and not used. |
Original Datagram Portion |
Variable |
Original Datagram Portion: The full IP header and the first 8 bytes of the payload of the datagram that prompted this error message to be sent. |
|
|
| |||||||||||||||||||
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.