Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The machine is running SuSE 11.2. I configured it to connect use DHCP by using the YaST2 graphical networking interface.

When I dhcpcd -k eth0 and then dhcpcd eth0 then I get a lease almost instantaneously and everything is good. However, if I ifdown eth0 and then ifup eth0 I don't get an IP address for about 20 seconds. Looking at network packet flow reveals that in the ifdown/up scenario, a dhcp request is broadcast successfully, but no response ever comes.
EDIT: The same thing happens during boot. A broadcast packet is sent before the link becomes active.

/var/log/messages reveals the following:

Dec 6 14:21:50 olm ifup: eth0 device: Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 21)
Dec 6 14:21:51 olm kernel: [ 3389.717366] tg3 0000:02:00.0: PME# disabled
Dec 6 14:21:51 olm kernel: [ 3389.936570] ADDRCONF(NETDEV_UP): eth0: link is not ready
Dec 6 14:21:51 olm ifup-dhcp: Starting DHCP4 client on eth0
Dec 6 14:21:51 olm dhcpcd[11807]: eth0: dhcpcd 3.2.3 starting
Dec 6 14:21:51 olm dhcpcd[11807]: eth0: hardware address = 00:10:18:30:60:3c
Dec 6 14:21:51 olm dhcpcd[11807]: eth0: broadcasting for a lease
Dec 6 14:21:51 olm ifup-dhcp: .
Dec 6 14:21:53 olm kernel: [ 3392.126437] tg3: eth0: Link is up at 1000 Mbps, full duplex.
Dec 6 14:21:53 olm kernel: [ 3392.126441] tg3: eth0: Flow control is on for TX and on for RX.
Dec 6 14:21:53 olm kernel: [ 3392.127000] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Dec 6 14:21:54 olm ifup-dhcp: .
Dec 6 14:21:55 olm avahi-daemon[3414]: Registering new address record for fe80::210:18ff:fe30:603c on eth0.*.
Dec 6 14:21:57 olm ifup-dhcp: .
Dec 6 14:21:59 olm ifup-dhcp:
Dec 6 14:21:59 olm ifup-dhcp: eth0 DHCP4 continues in background
Dec 6 14:22:04 olm kernel: [ 3403.004015] eth0: no IPv6 routers present
Dec 6 14:22:11 olm dhcpcd[11807]: eth0: timed out
Dec 6 14:22:11 olm dhcpcd[11807]: eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.info'
Dec 6 14:22:11 olm dhcpcd[11807]: eth0: adding IP address 172.26.59.123/26
Dec 6 14:22:11 olm dhcpcd[11807]: eth0: adding default route via 172.26.59.65 metric 0

Of particular note is that dhcpcd broadcasts for a lease before the eth0 link becomes ready. It never gets a response because the broadcast never actually went anywhere.

So my question is, Why does ifup-dhcp start the DHCP process before the link is ready? and how do I make it wait properly?

share|improve this question

2 Answers 2

I found out the reason why it asks for a lease before the link is ready. It is because ifup-dhcp does try to wait until the interface is ready before calling dhcpcd, but it uses the function is_iface_up which is defined in /etc/sysconfig/network/scripts/functions, and that function only checks to see if eth0 exists before returning a positive result.

I also found a (slightly) more long term solution. ifup-dhcp waits for a positive result from is_iface_up and then it waits an additional amount of seconds as defined by DHCLIENT_SLEEP which can be found in /etc/sysconfig/network/dhcp. By setting DHCLIENT_SLEEP="3", the interface now has time to become ready before dhcpcd is called, despite the fact that is_iface_up returns too soon. This is also less likely to be clobbered by updates.

share|improve this answer

If the box is on a network with spanning tree that may be the delay for the link becoming active. This shouldn't be a problem during a reboot but will be for a stop/start operation. You could always put a sleep in the ifup script, but that's really just kinda a hack. Another option would be to write in some logic to the ifup script to check the link status before making the dhcp call. Link could be checked with ethtool. Or you could just increase the dhcp client timeout. Modification to the ifup script is prone to be overwritten by updates.

share|improve this answer
    
Yes, there is spanning tree on this network. But this is most definitely a problem during boot. Looking at /var/log/messages after a boot, I see that the kernel does not give a "link becomes ready" until a full 3 seconds after ifup-dhcp has sent a dhcp broadcast request. Increasing the timeout doesn't help, because it will simply spend more time waiting for a response that will never come. –  Myrn Dec 6 '10 at 21:39

Your Answer

 
discard

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.