Server Fault is a question and answer site for system and network administrators. 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

Here's the problem:

root@home:~# ping
connect: Network is unreachable

root@home:~# dhclient eth0
RTNETLINK answers: File exists

root@home:~# ping 
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=51 time=16.8 ms
64 bytes from icmp_req=2 ttl=51 time=16.6 ms
--- ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 16.654/16.737/16.820/0.083 ms

Network is working only after I manually invoke dhclient. I don't have NetworkManager (removed it). Here are relevant lines from /etc/network/interfaces:

auto eth0
iface eth0 inet dhcp

And here is startup log:

root@home:~# cat /var/log/syslog | grep dhclient
May 28 21:39:44 home kernel: [    7.237076] type=1400 audit(1369762781.497:2): apparmor="STATUS" operation="profile_load" name="/sbin/dhclient" pid=405 comm="apparmor_parser"
May 28 21:39:44 home kernel: [    7.238298] type=1400 audit(1369762781.497:4): apparmor="STATUS" operation="profile_load" name="/usr/lib/connman/scripts/dhclient-script" pid=405 comm="apparmor_parser"
May 28 21:39:45 home dhclient: DHCPDISCOVER on eth0 to port 67 interval 8 (xid=0x79607e29)
May 28 21:39:45 home dhclient: DHCPREQUEST of on eth0 to port 67 (xid=0x79607e29)
May 28 21:39:45 home dhclient: DHCPOFFER of from
May 28 21:39:45 home dhclient: DHCPACK of from
May 28 21:39:45 home dhclient: bound to -- renewal in 234779 seconds.
May 28 21:39:45 home kernel: [   11.695666] type=1400 audit(1369762785.953:10): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=1154 comm="apparmor_parser"
May 28 21:40:11 home dhclient: DHCPREQUEST of on eth0 to port 67 (xid=0x2aa61c47)
May 28 21:40:11 home dhclient: DHCPACK of from
May 28 21:40:11 home dhclient: bound to -- renewal in 243414 seconds.

Any ideas what may cause such problem?

Update: I found that default gateway is not added on boot, but it is added when I restart networking service or run dhclient manually. But i didn't found yet what causes such behavior.

share|improve this question


Generally speaking you should get your default gateway from your DHCP server via Option 003. The best approach would be to configure your DHCP server to correctly provide this information to clients. If you can't do that for whatever reason, I believe you can manually specify it in your /etc/network/interfaces file using the gateway directive (see manpage). I've never done this but I believe it should work for interfaces that aren't statically configured.

If it doesn't you can manually add it using an init script.

It looks like you are correctly receiving a DHCP lease using dhclient. I suspect that NetworkManager was not completely removed or you have another network autoconfiguration utility that is starting (perhaps tied to your desktop environment) and attempting to re-configure your networks settings.

First confirm that your /etc/network/interfaces is configured correctly by running the networking init script:

sudo /etc/init.d/networking restart

or by just using ifup and ifdown:

sudo ifdown eth0 && ifup eth0

Then make sure you don't have any lingering traces of Network Manager:

sudo apt-get purge network-manager
share|improve this answer
Either of those two commands successfully repairs network. I already purged Network Manager and related stuff and my desktop environment doesn't start on boot. – Poma May 29 '13 at 17:49

In my case, under CentOS 6/Fedora this was related to an inconsistency between /etc/sysconfig/network-scripts/ifcfg-eth0 and /etc/udev/rules.d/70-persistent-net.rules .

In both files, the MAC associated to the eth0 interface is declared. On a VM clonation, a new MAC was assigned but not reflected here (the admin should have done that).

When booting up, you can see in dmesg that the real eth0 is renamed to eth1 (enters in conflict with ifcfg-eth0), then a new entry is automatically created under 70-persistent-net.rules associating the found MAC to eth1.

dhclient did not start (or if started, aborted) - the result being that the system didn't get an IP from the DHCP server.

Remarkably enough, running dhclient manually forces the acquisition of an IP for the fake eth1 and the network works normally after that.... until the next reboot.

Manually editing the files cited above so that MAC and eth* names are coincident has fixed the issue - now dhclient starts at boot & gets the IP by itself.

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.