Ask Your Question

ICMP - Yet another destination unreachable - Rookie

asked 2021-04-16 10:00:30 +0000

HappySailor gravatar image

updated 2021-04-16 10:01:54 +0000

Hi there, I am no Wireshark neither packet capture expert, nevertheless I am attempting to understand why a SIP/TLS app is not behaving as expected, so I have attached wireshark to a mirrored port on our switch, which mirrors all traffic on the PBX network.

What comes to my eyes is that we have some ICMP errors:

No.     Time               Source                Destination           Protocol Length Info                                   DSCP    1056 11:27:32.748536                ICMP     174    Destination unreachable (Port unreachable)         Class Selector 6,Default

Frame 1056: 174 bytes on wire (1392 bits), 174 bytes captured (1392 bits) on interface \Device\NPF_{--------HIDDEN----------}, id 0
    Interface id: 0 (\Device\NPF_{--------HIDDEN----------})
    Encapsulation type: Ethernet (1)
    Arrival Time: Apr 16, 2021 11:27:32.748536000 W. Europe Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1618565252.748536000 seconds
    [Time delta from previous captured frame: 0.000332000 seconds]
    [Time delta from previous displayed frame: 0.000332000 seconds]
    [Time since reference or first frame: 56.350984000 seconds]
    Frame Number: 1056
    Frame Length: 174 bytes (1392 bits)
    Capture Length: 174 bytes (1392 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:icmp:ip:udp:dns]
    [Coloring Rule Name: ICMP errors]
    [Coloring Rule String: icmp.type eq 3 || icmp.type eq 4 || icmp.type eq 5 || icmp.type eq 11 || icmpv6.type eq 1 || icmpv6.type eq 2 || icmpv6.type eq 3 || icmpv6.type eq 4] Ethernet II, Src: Panasoni_yy:yy:yy (xx:xx:xx:xx:xx:xx), Dst: PeplinkI_xx:xx:xx (yy:yy:yy:yy:yy:yy)
    Destination: PeplinkI_xx:xx:xx (yy:yy:yy:yy:yy:yy)
        Address: PeplinkI_xx:xx:xx (yy:yy:yy:yy:yy:yy)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Panasoni_yy:yy:yy (xx:xx:xx:xx:xx:xx)
        Address: Panasoni_yy:yy:yy (xx:xx:xx:xx:xx:xx)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800) Internet Protocol Version 4, Src:, Dst:
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 160
    Identification: 0xfaa4 (64164)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment Offset: 0
    Time to Live: 64
    Protocol: ICMP (1)
    Header Checksum: 0xbece [validation disabled]
    [Header checksum status: Unverified]
    Source Address:
    Destination Address: Internet Control Message Protocol
    Type: 3 (Destination unreachable)
    Code: 3 (Port unreachable)
    Checksum: 0xbda8 [correct]
    [Checksum Status: Good]
    Unused: 00000000
    Internet Protocol Version 4, Src:, Dst:
        0100 .... = Version: 4
        .... 0101 = Header Length: 20 bytes (5)
        Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
            0000 00.. = Differentiated Services Codepoint: Default (0)
            .... ..00 ...
edit retag flag offensive close merge delete


This packet has a lot of good information. This is only a small bit of what you can extract from the decode. Per Wireshark, this is a duplicate. You will need the user symptoms, topology and traceroute to isolate the issue(s).

  1. The SIP device sent a DNS query for mobile-sip-1277875736.ap-northeast-1.... to (Google DNS). This is probably the SIP agent.
  2. The DNS response from, to, User Datagram Protocol, Src Port: 53, Dst Port: 63882 with the A record information.
  3. The, Dst: sent ICMP response. I am here, but UDP port 63882 is not active.(ICMP type 3 code.3).

Packet decode information The original packet info: Src:, Dst:, User Datagram Protocol, Src Port: 53, Dst Port: 63882.
DNS response to mobile-sip-1277875736 ...(more)

BigFatCat gravatar imageBigFatCat ( 2021-04-18 06:39:43 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2021-04-16 12:51:34 +0000

SYN-bit gravatar image

Hello and welcome to the wonderful world of packet/protocol analysis.

Apparently the error is thrown by IP (PBX) attempting to ping (Google DNS), which is reachable. Is this normal?

Well, not all ICMP packets are a result of ping. Ping uses type 8 (echo) and 0(echo-reply).This ICMP packet is of type 3 (Destination Unrechable) and code 3 (port unreachable). In the ICMP payload is the first part of the IP datagram that triggered this ICMP message. In it, you can see that there was a DNS response from port 53 (DNS) to your PBX on port 63882. But the PBX had it's port already closed.

This happens quite often. A system will sometimes send multiple DNS requests and when one response is received, it moves on and closes the ports of the other outstanding requests. So when a (later) response comes in, it finds the port closed and an ICMP message is generated.

In your trace you will can filter on dns to view all DNS requests. And you will (hopefully) see this happen.

edit flag offensive delete link more


Hello there and thanks for helping! One question, why does this packet exists ICMP if the reply (in the payload) actually contains a reply from Shouldn't there be only a packet with source and dest ??

HappySailor gravatar imageHappySailor ( 2021-04-16 13:26:37 +0000 )edit

ICMP messages are like error messages. So the DNS server sends the response back to the PBX, but the port from which the request was sent (63882) was already closed. The TCP/IP stack on the PBX sees this packet, but It can no longer deliver it to any application (the DNS resolver that made the request was already finished), so it sends an error message back to telling it that it could not deliver the packet.

Have a look at RFC 792 for more detailed information on the workings of ICMP :-)

SYN-bit gravatar imageSYN-bit ( 2021-04-16 13:35:47 +0000 )edit

Thanks a lot, this makes sense! :-)

HappySailor gravatar imageHappySailor ( 2021-04-16 13:39:21 +0000 )edit

I would most definitly look at the preceding DNS packets. Is there anything off with the timeing? If not, I would seriously doubt the sanity of the DNS client. Send a request, get a response and then decide you can't handle the response. That is as close to insanity as you can get as an application.

Needless to say I see a lot of mobile devices actually showing this sort of insanity on a guest wifi.

hugo.vanderkooij gravatar imagehugo.vanderkooij ( 2021-04-19 07:30:41 +0000 )edit

Thanks Hugo! I would upvote, but cannot as just subscribed. Thanks for adding your thoughts!

HappySailor gravatar imageHappySailor ( 2021-04-19 07:55:05 +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


Asked: 2021-04-16 10:00:30 +0000

Seen: 5,299 times

Last updated: Apr 16 '21