2
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.

closed as too broad by Stephen Kitt, Rui F Ribeiro, Archemar, terdon Jun 19 '17 at 14:55

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • so many reasons. Bad Network Cable, ICMP echo turned off on the far side, Firewall Rules, etc... etc... – AfroJoe Jun 19 '17 at 12:29
  • @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. – sourcejedi Jun 19 '17 at 12:54
  • 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 :-). – sourcejedi Feb 6 at 20:18
3

[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 :-).


Previous version:

What can be the probable reason behind not able to ping?

AfroJoe: so many reasons

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?

AfroJoe: so many reasons

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 have a cable that works just well enough to detect a link, but not enough to reliably carry data packets.
2

There could be one of fifteen billion reasons. Some of them are listed below:

  • Network Configuration Issue on your desktop. (Did you set up the proper Gateway?)
  • Target system firewall configured to NOT reply to pings
  • Bad network cable connecting you to the network
  • Your system has firewall rules blocking ICMP replies from other hosts
  • Firewall configuration network-wide filters out ICMP (includes switch configurations)

The problem is, with just the information provided there is absolutely no way at all to do any further diagnostics, making this question "too broad" (flagged as such).

  • Yes, with the exception that out of these only 1) bad network cable or 2) network configuration issue on your desktop other than Gateway is possible. (Or at least "probable" as per Q). – sourcejedi Jun 19 '17 at 12:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.