Destination Host Unreachable
I am using Linux laptop and try to ping a Win10 laptop. I ping myself (Linux system) and google.com, both works, which means the IP connection to router and DNS have no problem. But I still got ‘Destination Host Unreachable’ error. Please enlighten. Thank you.
root@imx8mnlego:~# ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:22 errors:0 dropped:0 overruns:0 frame:0 TX packets:22 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:2156 (2.1 KiB) TX bytes:2156 (2.1 KiB) wlan0 Link encap:Ethernet HWaddr 3C:E1:A1:E0:00:80 inet addr:192.168.0.128 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::3ee1:a1ff:fee0:80/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1894 errors:0 dropped:0 overruns:0 frame:0 TX packets:9943 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3000 RX bytes:91940 (89.7 KiB) TX bytes:2469289 (2.3 MiB) root@imx8mnlego:~# ping 192.168.0.128 PING 192.168.0.128 (192.168.0.128) 56(84) bytes of data. 64 bytes from 192.168.0.128: icmp_seq=1 ttl=64 time=0.109 ms 64 bytes from 192.168.0.128: icmp_seq=2 ttl=64 time=0.122 ms 64 bytes from 192.168.0.128: icmp_seq=3 ttl=64 time=0.122 ms ^C --- 192.168.0.128 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2031ms rtt min/avg/max/mdev = 0.109/0.117/0.122/0.013 ms root@imx8mnlego:~# ping google.com PING google.com (216.58.194.206) 56(84) bytes of data. 64 bytes from sfo03s01-in-f14.1e100.net (216.58.194.206): icmp_seq=1 ttl=118 time=15.1 ms 64 bytes from sfo03s01-in-f14.1e100.net (216.58.194.206): icmp_seq=2 ttl=118 time=18.2 ms 64 bytes from sfo03s01-in-f14.1e100.net (216.58.194.206): icmp_seq=3 ttl=118 time=19.3 ms ^C --- google.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 15.101/17.579/19.375/1.810 ms root@imx8mnlego:~# From 192.168.0.146 icmp_seq=1 Destination Host Unreachable [closed]
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
root@prateek-desktop:~# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. From 192.168.0.146 icmp_seq=1 Destination Host Unreachable From 192.168.0.146 icmp_seq=2 Destination Host Unreachable From 192.168.0.146 icmp_seq=3 Destination Host Unreachable root@prateek-desktop:~# netstat -rn Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 What can be the probable reason behind not able to ping ? Firewall has been disabled. 192.168.0.1 is the IP address of my wireless router which is DHCP enabled. The ethernet port to that router has IP address assigned by DHCP. My PC has IP address 192.168.0.146. Both router and PC are having same network. My PC has Default gateway in network settings assigned as 192.168.0.146. My other devices can ping my PC, but my PC can not ping any other device including the router to which my PC is attached directly.
@AfroJoe Interestingly ICMP echo turned off on the far side will not generate this specific output, you wouldn’t get any ICMP reply lines at all. Traditional firewall rules would be the same. This output might happen with an ethernet router configured to only allow certain MAC addresses, if you were pinging that router.
I am not sure, but I think this might happen when you have a conflicting IP address on another device. So that you are actually pinging a different device, not your PC :-). I have edited my answer. I guess this is a very late answer, sorry :-).
2 Answers 2
[edit] My other devices can ping my PC, but my PC can not ping any other device including the router to which my PC is attached directly.
I would check for a conflicting IP address on another device.
(Even though I am not sure your ping results are consistent with this. It does not quite fit my intuition about ARP, and unfortunately I did not find any similar combination in Google Search results. Perhaps there is an additional problem or a different problem. But it is a nice thing to check, and it might help you find some clue).
On your PC, find what the MAC address («hardware address») is. If you run ip link show dev eth1 , the MAC address is the value shown after link/ether .
On one of the other devices, check carefully what MAC address it has cached for your IP, 192.168.0.146. If the other device runs Linux, you can check the ARP cache using ip -4 neigh . If the other device runs Windows, you can check the ARP cache using arp -a (in Windows command line). If it shows a different MAC address for your IP 192.168.0.146, then you were actually pinging a different device, not your PC :-).
What can be the probable reason behind not able to ping?
Technically, ping showing «Destination Host Unreachable» is a rather specific error message! Your output almost certainly means the ARP resolution is failing. On 192.168.0.146 . It looked like this was the same computer you ran ping on, and you confirmed that in a later edit. In that case, here is how you confirm an ARP issue:
$ ping 172.16.8.2 PING 172.16.8.2 (172.16.8.2) 56(84) bytes of data. From 172.16.8.205 icmp_seq=1 Destination Host Unreachable From 172.16.8.205 icmp_seq=2 Destination Host Unreachable From 172.16.8.205 icmp_seq=3 Destination Host Unreachable ^C --- 172.16.8.2 ping statistics --- 4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms pipe 4 $ ip -4 neigh 172.16.8.1 dev wlp2s0 lladdr 74:44:01:86:42:d6 REACHABLE 172.16.8.2 dev wlp2s0 INCOMPLETE Successful ARP resolution involves an exchange like this:
$ sudo tcpdump -n -i wlp2s0 arp or icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes . 13:43:49.469349 ARP, Request who-has 172.16.8.1 tell 172.16.8.205, length 28 13:43:49.470046 ARP, Reply 172.16.8.1 is-at 74:44:01:86:42:d6, length 28 13:43:49.852608 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 21, length 64 13:43:49.854600 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 21, length 64 13:43:50.853879 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 22, length 64 13:43:50.855867 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 22, length 64 ^C 18 packets captured 18 packets received by filter 0 packets dropped by kernel (observed while running ping, and forcing an ARP refresh using ip neigh flush dev wlp2s0 ).
Note: this interpretation basically only applies to ping . It does not apply when you get a «Host Unreachable» message from a «normal» TCP/IP application like ssh or curl , because that might also mean you received an ICMP error reply such as «Administratively prohibited» (from a firewall). However ping receives and decodes the entire ICMP reply. So ping would tell you that the error was specifically «Administratively prohibited», not just «Host Unreachable».
Also, this Q&A is about IPv4. I have not checked how it could be adapted for IPv6.
Why does ARP resolution fail?
I have one other piece of secret knowledge. Unless your Ubuntu client system was deliberately configured by someone, the address 192.168.0.146 was assigned through an exchange of DHCP packets. Typically this exchange would involve the router, although in other cases it might only involve a Windows Server or other type of server. In this case where the router is the DHCP server or relay, your system was already able to exchange some packets with the router.
You can test re-triggering the DHCP exchange by breaking and re-making the connection.[*] Of course if the problem keeps coming back again «randomly», doing this does not solve the underlying problem, and you might want to investigate the connection while it is still broken.
([*] Apple wrote an optimization which can do the DHCP exchange after an exchange of specific ARP packets. Maybe there are new quirks with this, but I have not seen it used on Linux yet.)
It is common to see this error with a connection using DHCP and WiFi, when the wireless signal is lost at some point. (And you catch it before the wireless layer had given up entirely. I’m not sure why I’ve seen that so many times, perhaps I was observing buggy or badly written systems). But eth1 is not a WiFi connection.
I believe that DHCP for IPv4 operates without requiring any ARP. At least in the initial DHCP exchange.
Remaining possibilities
From the facts in the initial version of your question I struggled to think of any individual scenario which is particularly common. (Including my implicit assumptions. It’s unlikely that someone would post this question without trying to plug their computer in to an operational router).
- The network you’re connected to has no device with the address 192.168.0.1 . If that’s what gave you a DHCP address, then it was removed from the network. Unplugged, or just died.
- You configured eth1 manually AND one of
- you’re not using NetworkManager in Ubuntu Desktop, and
- you don’t actually have an ethernet link detected (check ethtool ).
- Or you have an ethernet link detected, but the switch requires you to provide a password or other authentication using 802.1X.
- Or you have an ethernet link detected, but you’re required to register your computer’s MAC address with the network administrator.
- you’re not using NetworkManager in Ubuntu Desktop, and