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