Understanding the ICMP Protocol (Part 2)

If you missed the previous article in this series please read, Understanding the ICMP Protocol (Part 1).

Well we now know that ICMP is actually a very important protocol in the grand scheme of things. Without it we would never know what happened in the case of an error encountered by our packets on the network, or Internet for that matter. That is why ICMP is one of the four core protocols. All TCP/IP stack implementations have these four core protocols in them for that very reason. They are needed for the operating system to function, and communicate effectively. Without them computers would not function and the Internet would not be as we know it today.

On that note, how about we take a look at some other ICMP error messages that we are likely to encounter. Encounter that is, if you were sniffing your connection, and thereby collecting packets.

There is nobody listening

We know that if you send a TCP/IP packet to a port that does not have a service listening on it, that you will get a RST packet back. This lets you know that there is no service there. What happens if you send a UDP/IP packet to a port that has no UDP based service listening on it? Well something completely different then what happens to a TCP based connection. Let’s take a look at the packet below for an explanation of what happens.

00:00:05.579927 > icmp: udp port 64032 unreachable (DF) (ttl 50, id 64521, len 56)
0x0000      4500 0038 fc09 4000 3201 97fc c0a8 0164  [email protected]….’Z.
0x0010      c0a8 01c8 0303 01c9 0000 0000 4500 00f2  …………E…
0x0020      d385 4000 f011 01b6 c0a8 0164 c0a8 01c8  ..@……….’Z.
0x0030      0035 fa20 00de 0000                      .5……

When you send a UDP based packet to a port such as port 53 (DNS protocol listens on port 53) but there is nothing there, the destination computer would generate an ICMP based packet. The packet would pretty much exactly look like the one above. It is time to realize now that UDP, and ICMP have a sort of symbiotic relationship. Whereas TCP will have RST packets, and the such sent back, UDP will however have ICMP error messages instead. Those messages will indicate what happened to the packet that was sent.

So what does “udp port 64032 unreachable” actually mean? Well, it means that the destination computer does not actually have a service running on it. For example if the destination port number was 53, then that would mean that there is no DNS server running on that computer. This is how the source computer would find out that there is no such service. The resulting ICMP error message would tell it as much.

That is all well and good, but how does that ICMP error message tell the source computer exactly what packet it was that caused the ICMP error message to be generated? That is an excellent question. The way that ICMP works is that it will use IP to carry it around, and following the actual ICMP header will be the IP header, and first eight bytes of the transport protocol that actually caused the error to begin with. A tad confusing, I realize, but please look at the packet above. I have underlined the portion, which shows the original packet that caused the ICMP error message to begin with. That, in turn, is being returned to its owner via IP, and the ICMP packet header.

This way when the source computer receives this ICMP error message it will look at the IP header being carried, and the transport protocol as well. Remember now, that within the first four bytes of the transport protocol, are the port numbers. Both source and destination are there. This way the source computer is able to tell which process it was that needed to be made aware of the error i.e.: port 1124, and this is the ephemeral port that was assigned to Internet Explorer was it started up by the user.

Now we can also tell what exact type of ICMP error message this is by the type and code. This is seen in the above bolded part of the packet. This is the standard ICMP header. Please now refer to your TCP/IP cheat sheet, to break out the fields.


The first 03 refers to the type of ICMP error message, and in this case the sheet tells us that is Type “Destination Unreachable”.  Following that is another 03 and that refers to the code, which is “Port Unreachable”. So far so good, as this is exactly what the packets tells us in the ascii in the header part.


This value is the checksum of the ICMP header. If you remember every core protocol has a checksum field. This is computed by the source computer, and then recalculated by the destination computer. It basically is used to make sure that the protocol header itself was not corrupted on the way to its destination. The only exception is UDP, which does not have to use the checksum value in its header. The last four bytes as shown by the 0000 0000 are simply set to zero as there is nothing message specific to be conveyed in the header.

That pretty much wraps up the destination unreachable error message. The last one we will look at is the “admin prohibited filter” error message.

00:00:13.953415 > icmp: host unreachable – admin prohibited filter (ttl 255, id 57951, len 56)
0x0000      4500 0038 e25f 0000 ff01 81e6 c0a8 0164  E..8._………a
0x0010      c0a8 01c8 030d fcf2 0000 0000 4500 001c  ..Y………E…
0x0020      30f2 0000 3a01 6848 c0a8 0164 c0a8 01c8  0…:.hH..Y…1.
0x0030      0800 6f16 a8c3 e025                      ..o….%

This type of message was in all likelihood generated by a router. In all likelihood, the router which has the destination source IP shown above. That configuration would be done by the administrator of the router who has perhaps set an ACL barring communication attempts from the source IP in question. This is often done by some companies if they find repeat offenders trying to penetrate their networks. They will simply set up an ACL denying access to the IP in question. That would in turn generate the message above.

Once again, I have bolded the ICMP header, and underlined the IP and protocol that IP was carrying when the original error was created. Can you figure out what the protocol was that followed the IP header in this packet? I have bolded the first two bytes of the protocol. It was actually a ICMP Echo request that was sent, and that resulted in the router saying NO! we do not allow ICMP echo requests to be accepted. That is why we saw the “admin prohibited filter” message. The admin set up the router to deny any inbound ICMP Echo request packets.

Well as you can now see there is actually a lot to the ICMP protocol. There are plenty more ICMP error messages, which can be generated. I would encourage you to try your hand at packet crafting. This will allow you to put theory into practice. That way you can simulate various packet conditions, and then study the responding packets. It is a great way to learn more about TCP/IP. On that note, I sincerely hope you found this article of use to you, and I welcome your comments. Till next time!

If you missed the previous article in this series please read, Understanding the ICMP Protocol (Part 1).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top