Red Hat Bugzilla – Bug 425877
network configurion with DHCP fails
Last modified: 2014-03-16 23:11:45 EDT
Description of problem: init script is not able to set network when DHCP is taking longer to respond (other GNU/Linux distributions such as Debian does not have any problem configuring it correctly. Windows also picks up the settings without any manual intervention). If I run dhclient manually on eth0 it configures the network correctly. Version-Release number of selected component (if applicable): initscripts-8.60-1 How reproducible: DHCP server that takes longer to respond Steps to Reproduce: 1. 2. 3. Actual results: Fails with a message no link present Expected results: Properly configured network Additional info: pravi@localhost:~$ sudo /etc/init.d/network start Bringing up loopback interface: [ OK ] Bringing up interface eth0: Determining IP information for eth0... failed; no link present. Check cable? [FAILED] RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists RTNETLINK answers: File exists pravi@localhost:~$ sudo /sbin/dhclient eth0 Internet Systems Consortium DHCP Client V3.0.6-Fedora Copyright 2004-2007 Internet Systems Consortium. All rights reserved. For info, please visit http://www.isc.org/sw/dhcp/ wmaster0: unknown hardware address type 801 wmaster0: unknown hardware address type 801 Listening on LPF/eth0/00:1a:4b:70:50:aa Sending on LPF/eth0/00:1a:4b:70:50:aa Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13 DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15 DHCPOFFER from 10.11.0.1 DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPACK from 10.11.0.1 bound to 10.11.3.241 -- renewal in 9518 seconds. pravi@localhost:~$ The system is a Compaq 6510b [root@localhost ~]# mii-tool eth0 eth0: negotiated 100baseTx-FD, link ok [root@localhost ~]# lspci |grep -i ethernet 18:00.0 Ethernet controller: Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02) [root@localhost ~]# dmesg |grep -i ethernet eth0: Tigon3 [partno(none) rev b002 PHY(5787)] (PCI Express) 10/100/1000Base-T Ethernet 00:1a:4b:70:50:aa [root@localhost ~]#
Set LINKDELAY if your network card takes a while to negotiate. See /usr/share/docs/initscripts-<version>/sysconfig.txt for details.
Thanks. I have set LINKDELAY=20 in /etc/sysconfig/network-scripts/ifcfg-eth0 as you have suggested and it worked. It would be a good thing to set this if the DHCP server took longer during installation (not much useful for a laptop though). Also it would be better to have a reasonable value for this variable by default - especially since Windows and Debian did not have any problem with this network at all. I think it should wait longer by default since DHCP the network won't function without an IP and it is configyred for DHCP. And also messages like "link is not present, check cable" won't help. Can we check if the cable is present with mii-tool and if it is present give a more logical error message like, "your DHCP server is taking longer to respond". Once again thanks for the help. I had to run dhclient manually every time I boot up the machine.
LINKDELAY has nothing to do with DHCP - it's that the actual link itself isn't coming up quickly (most likely due to switch configuration.)
I think the original poster has made a good point. If we know that in some environments the 5 second default wait is too little, why not just increase the default? Like he said, on other systems like Debian or Ubuntu, this doesn't happen. If the network takes 20 seconds to come up than it's sad, but there is no point in giving up in 5 seconds... Given that on most modern systems, the network connection is vital, not some small we can only invest 5 seconds in trying. I also ran across this problem today in a corporate environment. Luckily I knew - and thought about - LINKDELAY. Most users will never be able to figure this out. When they see the message "Determining IP information for eth0... failed; no link present. Check cable?" I would think of two things (implicated in the message) - DHCP and the cable - and both are clearly irrelevant. I think this issue should be reopened.