Bug 156884

Summary:	Default route not set at all if first network to run dhcpcd fails to connect
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Dave Rosky <d_rosky>
Component:	Network	Assignee:	Christian Zoz <zoz>
Status:	RESOLVED INVALID	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	suse-beta
Version:	Final
Target Milestone:	---
Hardware:	i686
OS:	SuSE Linux 10.0
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Dave Rosky 2006-03-10 00:44:46 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.

Comment 1 Dave Rosky 2006-03-10 05:14:35 UTC

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

Comment 2 Christian Zoz 2006-03-13 20:01:57 UTC

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.

Comment 3 Dave Rosky 2006-03-14 02:18:34 UTC

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

Comment 4 Christian Zoz 2006-03-14 07:55:18 UTC

We did that. It's default in the next products.