Ping sento no route to host

I

IshSwitz

Hello,
I'm fairly new to FreeBSD and I recently installed it (10.3) on my computer. The installation went well and after I rebooted I tried to ping google and was greeted by this: "ping: sendto: No route to host" I looked for a solution but I could not find one, any help will be greatly appreciated.
 
This is usually a route problem. Type netstat -rn and look if there is any default route. Also, check if your /etc/resolv.conf is pointing to the correct DNS.
 
IshSwitz said:
Would the default route look like an IPv6 address?
Click to expand...

Only if you have an IPv6-only network. There's essentially 3 scenarios: IPv4-only, IPv4 and IPv6 (dual stack), and IPv6-only. You need default routes for both, if both are enabled on your network (and both have Internet connectivity).

It might help if you let us see your /etc/rc.conf, to give us a better understanding of your configuration. You can make any names/addresses anonymous if you want to, just please do it consistently, e.g. if the real addresses for the system and router were 192.0.2.45 and 192.0.2.1, change them to xxx.0.2.45 and xxx.0.2.1. Keep things like netmask unchanged.

Please give a brief summary of your network/Internet connection. I.e. which of v4 and v6 are available, and how the FreeBSD system is connected towards the Internet.

It looks like you do have some connectivity, assuming you were doing something like ping www.google.com, and not using a raw address like ping 8.8.8.8, as your system apparently managed to resolve the address from the name. If you had no connectivity, or a problem with DNS resolution, you would see some other error, possibly the following:
Code: 
# ping unknown.example.org
ping: cannot resolve unknown.example.org: Unknown host

The following two commands should aid in diagnosis, letting you see how far packets are getting towards Google's public DNS servers: traceroute -n 8.8.8.8 (IPv4) and traceroute6 -n 2001:4860:4860::8888 (IPv6). Try first with the -n option to disable DNS lookups, then without it if the first test gets far enough that lookups might be useful.

"ping: sendto: No route to host" does normally mean that packets are not leaving your system (due to either lack of network or route), but the contradiction that you appear to have working DNS makes those traceroutes potentially interesting.
 
Murph said:
Only if you have an IPv6-only network. There's essentially 3 scenarios: IPv4-only, IPv4 and IPv6 (dual stack), and IPv6-only. You need default routes for both, if both are enabled on your network (and both have Internet connectivity).

It might help if you let us see your /etc/rc.conf, to give us a better understanding of your configuration. You can make any names/addresses anonymous if you want to, just please do it consistently, e.g. if the real addresses for the system and router were 192.0.2.45 and 192.0.2.1, change them to xxx.0.2.45 and xxx.0.2.1. Keep things like netmask unchanged.

Please give a brief summary of your network/Internet connection. I.e. which of v4 and v6 are available, and how the FreeBSD system is connected towards the Internet.

It looks like you do have some connectivity, assuming you were doing something like ping www.google.com, and not using a raw address like ping 8.8.8.8, as your system apparently managed to resolve the address from the name. If you had no connectivity, or a problem with DNS resolution, you would see some other error, possibly the following:
Code: 
# ping unknown.example.org
ping: cannot resolve unknown.example.org: Unknown host

The following two commands should aid in diagnosis, letting you see how far packets are getting towards Google's public DNS servers: traceroute -n 8.8.8.8 (IPv4) and traceroute6 -n 2001:4860:4860::8888 (IPv6). Try first with the -n option to disable DNS lookups, then without it if the first test gets far enough that lookups might be useful.

"ping: sendto: No route to host" does normally mean that packets are not leaving your system (due to either lack of network or route), but the contradiction that you appear to have working DNS makes those traceroutes potentially interesting.
Click to expand...

Here it is:
Code: 
hostname="eko"
Ifconfig_re0="DHCP"
Ifconfig_re0_ipv6="inet6 accept_rtadv"
local_unbound_enable="YES"
sshd_enable="YES"
moused_enable="YES"
ntpd_enable="YES"
#Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable 
dumpdev="AUTO"
 
Just an update I just downloaded gnome3 no problem however the ping issue still persists! I'm not exactly sure what's going on but I do have internet lol
 
IshSwitz said:
Just an update I just downloaded gnome3 no problem however the ping issue still persists! I'm not exactly sure what's going on but I do have internet lol
Click to expand...

Very weird indeed. I noticed that you have local_unbound enabled, did you try to disable it already? Don't forget to point /etc/resolv.conf to a valid DNS.
 
IshSwitz said:
Just an update I just downloaded gnome3 no problem however the ping issue still persists! I'm not exactly sure what's going on but I do have internet lol
Click to expand...

Ok, based on the information we currently have, it seems that you have a problem with IPv4, but IPv6 is working ok. ping(8) is IPv4 only, and ping6(8) is the IPv6 tool. I'd guess that ping6 www.google.com will probably work for you.

It looks like the problem is that you do not have a default route installed for IPv4, assuming that your Internet connection isn't IPv6-only. netstat -4rn will show you the IPv4 routing table, and you are looking for a route with a destination of default. Since it is being configured by DHCP, the issue may be a problem with the DHCP server's configuration. You can check /var/db/dhclient.leases.re0 to see what the DHCP server is sending to the system; a default route should appear as something like option routers 192.0.2.1; (but with the IPv4 address of your router/gateway).

If you are unfortunate enough to be on an IPv6-only Internet connection, my commiserations, and you need to investigate what provisions your ISP has made for you to access the IPv4 Internet. That would be via some form of NAT service, possibly a NAT64/DNS64 service. It is important to have IPv4 connectivity, as there are still many parts of the net that are IPv4-only. It will be a long time into the future before everything is available via IPv6, as there are still plenty of ISPs that are IPv4-only, and content providers that have not yet gone dual stack.
 
You must log in or register to reply here.
Back
Top