Network Computingwww.networkcomputing.com

Notes on Reading ICMP Error Messages

ICMP error messages can be overwhelming, to say the least. They present a lot of information that has be parsed through, deciphered, and generally made sense of.

The easiest way to read an ICMP error message is to break it into manageable chunks. The first portion of the message always identifies the specific ICMP error message being reported, while the remainder of the message consists of the headers and first eight bytes of data from the IP datagram that's being bounced.

For example, Figure 5-29 shows an ICMP Destination Unreachable: Host Unreachable Error message that appears to be very complex on the surface, but actually only consists of a few key pieces of data.

By following a few simple steps and answering some simple questions, you can easily decipher the source and cause of the ICMP error message. The questions are:

What is the Message Type?

The ICMP Message Type for this message is 3, which indicates that it is part of the Destination Unreachable family of error messages.

What is the Message Code?

The ICMP Message Code for this message is 3, which tells us that this particular Destination Unreachable error message indicates that the destination port was unreachable (this is different from the destination host or network being unreachable).

What does it mean?

We can tell from the discussion of Port Unreachable earlier in "Destination Unreachable error messages" that the Destination Unreachable: Port Unreachable error message means that the destination port number specified by the UDP or TCP message was not in a listening state, which generally indicates that there was no server running on that port number.

What other evidence is there?

Obviously, the most important piece of evidence for resolving this problem is looking at the destination port number sent in the original message. Since this is an ICMP error message, the original IP datagram has been provided in the message body, so all we have to do is find the Destination Port number field in the original datagram, which points to UDP port 69 (the well-known port for TFTP servers).

What conclusions can we draw?

We can tell that a host on our internal network tried to send a UDP message to the well-known port for TFTP servers on a remote server. Since the message was rejected, we can assume that this means that there was no TFTP server running on the destination system. Furthermore, we can also assume that this was not a configuration issue at the server, where it was configured to block access to this particular client, since the datagram would have cleared the server's UDP stack (although nothing else may have happened, the packet would have gone through and then been ignored, rather than being blocked at the gate by UDP).

Most ICMP error messages can be read using this same series of procedures. In almost all cases, all the information that you need to diagnose the cause of a failure is presented in the ICMP error message's headers, in the headers from the failing datagram, or in the first eight bytes of data from the failing datagram (which is where the source and destination port numbers are provided for TCP and UDP connections).