Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Since I upgraded my HP Proliant Server from Ubuntu 10.04 to 12.04, I am unable to:

  • ping
  • ping
  • browse the internet with Firefox
  • git fetch origin
  • cap deploy from a remote machine

I can however see my Rails application running on this server when I access it via its ip address within our corporate network.

I see the Networking icon in the GUI but "Wired Network" is greyed out.

Here is some other relevant info, based on the numerous similar but non-resolving threads I've browsed here at AU:

dean@dgwjasonfried:~$ ifconfig

eth0      Link encap:Ethernet  HWaddr 1c:c1:de:fa:cd:9f  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::1ec1:deff:fefa:cd9f/64 Scope:Link
          RX packets:40735 errors:0 dropped:0 overruns:0 frame:0
          TX packets:77215 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2806140 (2.8 MB)  TX bytes:113945803 (113.9 MB)

lo        Link encap:Local Loopback  
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  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:0 
          RX bytes:1872 (1.8 KB)  TX bytes:1872 (1.8 KB)

dean@dgwjasonfried:~$ lspci -nn | grep Ethernet

1e:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5723 Gigabit Ethernet PCIe [14e4:165b] (rev 10)


# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp



**Updated 3/19/13, after trying to follow some of the advice give in responses below and elsewhere:

dean@dgwjasonfried:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

**end of update

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    0      0        0 eth0   U     1      0        0 eth0     U     1000   0        0 eth0

**Updated to show NetworkManager.conf and evidence that the resolv.conf symlink is working for me

dean@dgwjasonfried:~$ cat /etc/NetworkManager/NetworkManager.conf


dean@dgwjasonfried:~$ ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 29 Mar 18 09:33 /etc/resolv.conf -> ../run/resolvconf/resolv.conf

**Updated to show latest resolv.conf after I deleted original in /etc/resolvconf/resolv.conf.d and cleared out the copy of original that was sitting in tail, then rebooted:

dean@dgwjasonfried:/etc/resolvconf/resolv.conf.d$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)

Note that the nameserver entries listed in an earlier resolv.conf version above are now gone. Also note that whereas I was briefly able to get ping to resolve the ip address for (but still not receive any packets back) I'm now back to my original situation where I get 'unknown host'.

**end of update

I'd be grateful for any help you could supply or suggestions you might have.


Dean Richardson

share|improve this question
Commenting the auto eth0 and iface eth0 - lines from /etc/network/interfaces will make eth0 appear at network-manager. Then add your nameservers graphically. – aquaherd Mar 11 '13 at 21:56
Thanks, aquaherd. You meant "commenting out"... correct? Also, when you say "add your nameservers graphically" do you mean through the Ubuntu desktop GUI? Can you please clarify that point for me? – Dean Richardson Mar 12 '13 at 21:18
Yes, I meant commenting out. I was wrong, there is no graphical nameserver GUI yet, unless you use a fixed IP-address. man 8 resolvconf might help you from there if your nameservers can't be retrieved from the DHCP-server. Manual edits of resolv.conf seem to be deprecated in favour of a resolvconf package that also provides DNS caching and adds some security against DNS spoofing. See also this question: – aquaherd Mar 13 '13 at 11:33
I have exactly the same problem. Also an HP Proliant Microserver using the Broadcom NetXtreme (BCM5723) Ethernet controller. – user140243 Mar 14 '13 at 13:35
I guess you have a problem with your routing table. Could you provide the output of route -n? – Huygens Mar 14 '13 at 14:18

I think it would be beneficial to step back, teach a man how to fish instead of just telling you what's wrong.

There are many components involved in making a good network connection

  • It can be the hardware: ethernet card, cable contacts, network interface on your directly connected switch, etc.
  • It can be the low level software: the kernel driver for your network card
  • It can be your routing table
  • It can be DNS

And these are all dependent on each other from the bottom up, e.g. if you can't route packets correctly, you can't reach your DNS service.

There's only one (sane) way to pinpoint the issue that I know of: one by one, by elimination.

One sentence stands out in your description:

I can however see my Rails application running on this server when I access it via its ip address within our corporate network.

It is great that you tried this. This piece of information is golden because it eliminates many possible causes. It means that your hardware and your (kernel) drivers and the connections inside the corporate network all look fine. This is also confirmed by the fact that the ifconfig output shows packets being sent and received and no (zero) errors, collisions, or retransmissions. At this point I'm sure your issue is in your configuration only.

I notice that your internal DNS server is at (non-public) IP:, this is not on your immediate subnet, you can tell this by this ifconfig output line:

inet addr:  Bcast:  Mask:

Note that your mask leaves only the last of the 4 octets as 0, meaning you're broadcasting only over the 10.24.5.x subnet. You may not have a full route to your internal DNS server.

The experiment I would do now would be to try and verify the routes to your essential components:

  1. Your gateway
  2. Your name server

It is essential to do these by IP since we don't yet know if your DNS server is ok and if you can talk to it.

# first traceroute the gateway:

If this fails with an error like no route to host or destination is unreachable, it is almost certain that your issue is in the routing table. If it is successful you've just made a huge step forward because routing is a big subject by itself.

# if successful traceroute the DNS server

If this fails, your issue may be that the netmask is too restrictive. Try to change it to You can set this in /etc/network/interfaces by adding:


under eth0.

Once you fixed this, you would need to restart your network:

sudo /etc/init.d/networking restart


share|improve this answer
Both traceroutes are successful: dean@dgwjasonfried:~$ traceroute traceroute to (, 30 hops max, 60 byte packets 1 ( 3.513 ms * * dean@dgwjasonfried:~$ traceroute traceroute to (, 30 hops max, 60 byte packets 1 ( 1.763 ms 2.008 ms 2.031 ms 2 ( 0.172 ms * * – Dean Richardson Mar 19 '13 at 16:23
Great, this is big progress. So you can reach your DNS server @ but seem to have no DNS service? Check your DNS by using a hostname: host some-internal-server-name does this work? Can you traceroute all the way to google's DNS service ? – arielf Mar 19 '13 at 16:52
dean@dgwjasonfried:~$ host has address dean@dgwjasonfried:~$ traceroute traceroute to (, 30 hops max, 60 byte packets 1 ( 1.412 ms 1.405 ms 1.396 ms 2 ( 0.754 ms 0.760 ms 0.978 ms 3 ( 10.173 ms 10.409 ms 10.404 ms 4 ( 13.867 ms 13.405 ms 13.675 ms 5 ( 9.630 ms 9.867 ms 9.864 ms 6 ( 10.561 ms 9.886 ms 10.110 ms 7 * * * – Dean Richardson Mar 19 '13 at 17:49
I get about 23 more lines with * * * down to line 30, and the command completes. – Dean Richardson Mar 19 '13 at 17:50
So everything seems to work fine. Your name-server responds, and you have a full route to external addresses. Can you try ping and ping again? – arielf Mar 20 '13 at 2:10

One of the problems is that resolvconf did not get configured properly. Ref: To fix this, run

    sudo dpkg-reconfigure resolvconf

This, however, can't be the reason that you cannot ping other machines by IP address.

share|improve this answer
When I issue the sudo dpkg-reconfigure resolvconf command in the terminal, I get a screen of text with <Ok> at the bottom. Unfortunately, this screen doesn't respond to any further input, so I can't page down to see the prompt to accept the option to create the symlink to /run/resolvconf/resolv.conf. Also, it appears this symlink exists for me already. – Dean Richardson Mar 18 '13 at 20:33
1. If the symbolic link /etc/resolv.conf -> ../run/resolvconf/resolv.conf already exists then, it's true, you don't need to run sudo dpkg-reconfigure resolvconf. 2. That you can't successfully run sudo dpkg-reconfigure resolvconf when you try surprises me. 3. I am surprised that the symbolic link exists because the resolv.conf that you showed was not written by the resolvconf utility. Is some other network interface configuration utility installed on the server which overwrites /etc/resolv.conf? If so then that may be implicated in the other trouble you are having. – jdthood Mar 19 '13 at 9:08
I updated the original post to display my current resolv.conf, which now appears to be managed by the resolvconf utility and displays some extraneous-looking content. This comes after commenting out dns=dnsmasq in NetworkManager.conf, then uncommenting it when the change didn't appear to help. – Dean Richardson Mar 19 '13 at 14:12
OK, the latest resolv.conf looks correct: it has the two familiar resolvconf comment lines, a search line and a nameserver line. The nameserver line has address, the loopback IP address where the NetworkManager-controlled instance of dnsmasq is presumably listening. If you comment out dns=dnsmasq and then do sudo restart network-manager you should instead see a non-loopback nameserver address on the nameserver line in resolv.conf; that's the nameserver address obtained from the DHCP server. While debugging I recommend you keep dns=dnsmasq commented out. – jdthood Mar 19 '13 at 21:00
Also note that it is safest to use either NetworkManager or ifupdown and not a mixture of the two. If you choose to use ifupdown then you should purge the network-manager package and configure your interfaces in /etc/network/interfaces. If you choose to use NetworkManager then /etc/network/interfaces should contain only the stanza for the lo interface and you should configure all interfaces^Wconnections with the NM Connection Editor. – jdthood Mar 20 '13 at 9:03
eth0      Link encap:Ethernet  HWaddr 1c:c1:de:fa:cd:9f  
      inet addr:  Bcast:  Mask:

10.* interfaces often have netmask Check that the netmask is correct for your LAN.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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