5

Using Ubuntu Server (12.04) via command line, I can access the LAN (e.g. ping local machines) but not the internet (e.g. "ping google.com" or "sudo apt-get update"). How should I troubleshoot this?

I'll start by saying that I was able to access the internet (using sudo apt-get) but after some 'configuration work' I can now only access the LAN. It previously worked when I had a DHCP connection. I noticed the problem some time after I'd switched to a static IP. I've switched back to DHCP but with no luck.

/etc/network/interfaces currently looks like this:

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto wlan0
iface wlan0 inet dhcp
wpa-ssid myrouterssid
wpa-psk myrouterpassword

ifconfig -a reports:

eth0      Link encap:Ethernet  HWaddr 00:1e:7a:d9:1b:07
          inet addr:192.168.0.101  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::21e:68ff:fed9:1b07/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:217 errors:0 dropped:0 overruns:0 frame:0
          TX packets:414 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:23826 (23.8 KB)  TX bytes:47487 (47.4 KB)
          Interrupt:16

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:16436  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:720 (720.0 B)  TX bytes:720 (720.0 B)

virbr0    Link encap:Ethernet  HWaddr 86:19:a7:9b:a6:4a
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr 00:94:ea:de:1f:78
          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::216:eaff:fede:1f78/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:328 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:58008 (58.0 KB)  TX bytes:1852 (1.8 KB)

"ping 192.168.0.1" (gateway) works. "ping 192.168.0.100" (self) works. "ping 192.168.0.7" (another PC) works. "ping google.com" reports "ping: unknown host google.com". "ping 173.194.34.72" (google.com) fails.

I can also SSH to this ubuntu server from another PC (although it now waits about 20 seconds before it asks for the password whereas it was previously instantaneous - significant?)

EDIT: route -n reports:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    100    0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
Improve this question
1
  • What are your routes for this machine? (hint route -n)
    – symcbean
    May 21, 2012 at 10:05

6 Answers 6

Reset to default
7

Your resolv.conf entries are probably bad. You should determine the proper address(es) and write them manually in resolv.conf (removing current entries).
I guess that DNS server is the same as gateway (192.168.0.1).

You can try this before making changes in resolv.conf by command:

dig @192.168.0.1 google.com

Above command tries to ask 192.168.0.1 (not Your current set in resolv.conf) for google.com IP, if there is working DNS server the answer will contain following text:

;; ANSWER SECTION:
google.com.             300     IN      A       173.194.35.162
google.com.             300     IN      A       173.194.35.161
google.com.             300     IN      A       173.194.35.164
[...]

If it fails try entering different IPs in dig command

Another problem is that trying to ping google by IP fails (as you wrote). To make a quick test why it fails try following command:

traceroute 173.194.35.162

You'll see which one of the hops causes the problem. It's possible that Your gateway is not working.

Improve this answer
2
  • Ah, fantastic. You're right it was the gateway that was the problem - there were some legacy filters on the IPs I wanted to use. When I switched to static IP I ended up on those IPs and when I switched back to DHCP the router left my PC on those IPs. Thanks to everyone for really useful answers and great troubleshooting tips. I'll vote up (as soon as I have enough privileges). @daftu thanks for spotting the underlying issue (which wasn't on the PC itself at all).
    – Paul Masri-Stone
    May 22, 2012 at 12:21
  • Just as a side note, I had this issue too, and the problem was that a computer had stolen the static ip address I had set.
    – leeand00
    Feb 25, 2015 at 19:09
5

Things to check:

You've got nameservers defined in /etc/resolv.conf

/etc/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4

You've got a default gateway in your routing table:

ip route

tom.oconnor@charcoal-black:~$ ip route
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.0.0/16 dev eth0  proto kernel  scope link  src 192.168.100.27 
default via 192.168.1.1 dev eth0  metric 100

Default route is the one that starts "default via"

Improve this answer
4
  • /etc/resolv.conf containst 2 nameservers: nameserver 194.168.4.100 nameserver 194.168.8.100. ip route reports default via 192.168.0.1 dev eth0 metric 100 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.101 192.168.0.0/24 dev wlan0 proto kernel scope link src 192.168.0.8 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
    – Paul Masri-Stone
    May 21, 2012 at 10:02
  • 1
    Your name servers are on .4.100 and .8.100 and your default route is 0.1...but your masks are 255.255.255.0. How would it see those DNS servers?
    – Bart Silverstrim
    May 21, 2012 at 14:06
  • @Bart You're saying that the masks mean that the nameserver IPs would be unreachable, right? Sorry I don't understand enough to see how these all hook together. Is it possible that as etc/resolv.conf is auto-generated perhaps these nameservers appeared here before I started having problems?
    – Paul Masri-Stone
    May 21, 2012 at 14:31
  • Do you have other machines in the same network that are working, and can you check their DNS server settings and/or mask settings?
    – Bart Silverstrim
    May 21, 2012 at 14:34
0

Sounds like your name resolution (DNS) is broken. Check your /etc/resolv.conf and the DNS settings of your network manager.

Improve this answer
3
  • I have 2 nameservers in /etc/resolv.conf. How do I check the DNS settings of my network manager (via command line)?
    – Paul Masri-Stone
    May 21, 2012 at 10:06
  • NB nmcli is not installed and without internet access I can't download & install it.
    – Paul Masri-Stone
    May 21, 2012 at 10:11
  • Use dig or host. Host is installed on most systems by default.
    – Kyle
    May 21, 2012 at 20:39
0

You haven't defined your default route. Your DHCP server for WiFi doesn't send information about it. Please, correct you DHCP configuration, or you must set it on the Ubuntu system by hand.

Improve this answer
0

This can happen because of a bogus IP/MAC binding in your router. Issue the ifconfig command, check your HWaddr against the router's IP/MAC binding table.

Improve this answer
0

Edit /etc/resolv.conf probably missing nameservers, then restart the network manager service NetworkManager restart.

Improve this answer
1
  • 1
    I don't see anything new in this answer. The accepted answer has the same suggestion with more detail.
    – kasperd
    May 5, 2016 at 11:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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