Ask Your Question

How to match ICMP Destination unreachable (Port unreachable) to original message

asked 2017-11-22 17:56:15 +0000

Nap gravatar image

updated 2017-11-23 08:26:57 +0000

[VirtualBox 5.1.30 r118389 (Qt5.6.3), HOST: MacBook Pro High Sierra 10.13.1, GUEST: Ubuntu 14.04 LTS]
[Wireshark 2.2.7 (v2.2.7-0-g1861a96)]

I was having some local domain resolution problems with a DNS server I have setup inside a VirtualBox 'Host-Only' network that I think I've now fixed. The server would sporadically resolve my local (internal access only) domains but later refuse to resolve them (only to recommence resolution some time later). I used Wireshark to help me debug the above problem. The symptom of the problem seemed to be that my HOST was generating a lot of ICMP Destination unreachable (Port unreachable) packets that were being sent back to my DNS server.

Over the last few hours, my DNS resolution seems stable and the number of these packets has reduced significantly. Whilst things are looking much better here, I am still getting a few of these packets periodically and I would like to fix the issue that is causing them, whilst I have the momentum.

Whilst investigating the problem and searching the web, I came across a short thread in google groups: 10.6 DNS resolution, does not obey DNS server priority from DHCP that intrigued me. Of particular relevance is a thread which Andy references, and I'm wondering if this issue with mDNSResponder, or something similar, still exists as I believe it could explain the problem I'm having.

10.6 (Snow Leopard) all DNS queries now go via mDNSResponder. mDNSResponder queries for both the "A" and "AAAA" record, but after the first response it cancels the queries and shuts down the socket so that all other responses are rejected (port unreachable).

In my case, I have IPv6 resolution turned off in my DNS server, so I'm only asking for A records. But I'm wondering if mDNSResponder is closing the ephemeral ports before the responses are returned, a kind of accounting problem? Not being a regular user of Wireshark, I am having difficulty matching the requests with responses, so my question is:

How can I match the ICMP Destination unreachable (Port unreachable) error report packet from the HOST to the packet that cause the error; ie, which query response was not delivered? (See black/selected blue packets in the image below.)

image description

(URL to the image is:

Here is a breakdown of such a packet, and from what I can see, it is not following the RFC792 format, as per the example shown below. Contrary to RFC792, the 1st 6 bytes of the packet are the Mac Address of the Server hosting the DNS....

Here is the data in a ICMP Destination unreachable (Port unreachable) packet, as an image (couldn't figure out how to copy/paste it): image description
(URL to the image is:

Here is Wireshark's decoding of the packet:

Frame 876: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface ...
edit retag flag offensive close merge delete


from what I can see, it is not following the RFC792 format, as per the example shown below. Contrary to RFC792, the 1st 6 bytes of the packet are the Mac Address

Yes, you have misinterpreted something. RFC 792 says that the bytes after the 8-byte ICMP header will be the "Internet Header + 64 bits of Original Data Datagram", which is what's after the Unused: 00000000.

Guy Harris gravatar imageGuy Harris ( 2017-11-23 08:51:34 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2017-11-22 20:16:26 +0000

Guy Harris gravatar image

If you look at the packet details for the port unreachable messages, you should see at least the first 64 bytes of the packet that caused the error, as per pages 4 and 5 of RFC 792. Wireshark should dissect those bytes, which might show you what was being queried.

edit flag offensive delete link more


Thanks. I've had a look at the specification but it does not seem to apply to what Wireshark has captured. I've updated my OP to demonstrate the fact. Perhaps I've misinterpreted something?

Nap gravatar imageNap ( 2017-11-23 08:28:29 +0000 )edit

Unfortunately, I misread "64 bits" as "64 bytes"; all RFC 792 guarantees you is 8 bytes, which is enough to tell the host that receives that ICMP message what the IP source and destination address, and TCP or UDP source and destination port, of the failing packet are. The only thing you can do is look for a DNS request coming from port 65045.

Guy Harris gravatar imageGuy Harris ( 2017-11-23 08:49:12 +0000 )edit

Yes, matching the port number!

Nap gravatar imageNap ( 2017-11-25 05:58:44 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2017-11-22 17:56:15 +0000

Seen: 26,856 times

Last updated: Nov 23 '17