Bugzilla – Bug 156884
Default route not set at all if first network to run dhcpcd fails to connect
Last modified: 2006-03-14 07:55:18 UTC
If a network configured to use dhcp fails to connect, the dhcpcd process is backgrounded. If a second network configured to use dhcp then is able to connect, a default route is not set on that network. I'm not sure, but this appears to be because the existence of the first dhcpcd process keeps the second one from setting a default route, even though the first dhcpcd process was never able to complete a negociation. This causes, for example, no default route to be set on a wireless connection if the wired connection is attempted to be brought up first but there is no cable plugged in. Likewise, if a wireless connection fails (with dhcpcd running in the background), and a wired connection is then brought up, no default route is set on the wired connection. It appears that dhcpcd will only set a default route on one network interface. This is causing a problem if the first network that dhcpcd is run on cannot connect. For example, if machine has both a wired and wireless network card, if dhcpcd is first run on the wireless card but the wireless card cannot connect, dhcpcd appears to not set a default route on the wired interface, which does connect, because dhcpcd continues in the background trying to negociate on the non-functioning wireless interface. The same problem occurs if dhcpcd is first run on the wired interface with no cable conneced and the wireless interface is able to connect. The dhcpcd process running on the non-connected wired interface appears to keep the dhcpcd process on the connected wireless interface from setting the default route.
I looked through the ifup-dhcp script, and indeed the script unsets DHCLIENT_SET_DEFAULT_ROUTE if there is already another dhcpcd running or scheduled. The problem is that the already-running dhcpcd could be running indefinitely on an interface waiting for it to come up, and will proclude another interface from setting a default route. Perhaps it would be better to check for the existence of a default route, rather than check for the existence of a pre-existing dhcpcd process. Dave
This works as expected. Try STARTMODE=ifplugd and IFPLUGD_PRIORITY=<N> in your interface config files, with N for ethernet bigger then N for wlan. (Or set it via YaST, or read 'man ifcfg'). This will help you. Alternatively (but worse) you can set DHCLIENT_PRIMARY_DEVICE=yes/no. See ifcfg.template.
STARTMODE=ifplugd does work, thanks. If this is the preferred way to address the problem, then how about consider making this the default mode? This would avoid people having to troubleshoot the problem. Dave
We did that. It's default in the next products.