Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 269904

Summary: With wpa-supplicant, sys-apps/baselayout 1.* and 2.*/openrc's 'need net' dep fails to check for a working network interface
Product: Gentoo Hosted Projects Reporter: Rick Harris <rickfharris>
Component: OpenRCAssignee: OpenRC Team <openrc>
Status: CONFIRMED ---    
Severity: normal CC: darkside, DuPol, mmokrejs, sebastian
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard: openrc:oldnet
Package list:
Runtime testing required: ---

Description Rick Harris 2009-05-15 00:51:12 UTC
Really happy with the new baselayout/openrc but one annoying bug that has carried over from stable baselayout is the lack of a strong 'need net' dependency check.

Currently the only criteria for the dependency to be met is that the init script providing 'net' be started, which in turn leads to failure of other init scripts depending on 'net' when a valid network connection is not present.
A common scenario is that DHCP, ppp and wireless authentications usually require some time to pass before receiving an IP address, so while the relevant 'net' service has been started, the 'need net' services have attempted to start and failed before the 'net' service has finished configuring the interface.

One way to implement the check is to have a user-defined timeout variable in /etc/rc.conf in seconds to wait before any network interface (besides net.lo) receives or gains an IP address.
I touched on this idea in bug #268598 with a patch to introduce for baselayout-1.*

By all means, shoot me down with a better way.
Am happy to test but would like this feature be added, it would also fix bug numbers #253416 and #266875

Thanks :)
Comment 1 Rick Harris 2009-08-20 02:28:55 UTC
Found an easy fix (tested on baselayout-2 only using DHCP) by editing /lib/rc/net/wpa_supplicant.sh in function wpa_supplicant_pre_start(), change the lines...
        if eend $?; then
               ebegin "Backgrounding ..."
               exit 1
        fi

to read...
        if eend $?; then
#               ebegin "Backgrounding ..."
#               exit 1
                return 0
        fi


This way the init script execution process will not fork off and lead to further 'net' dependant scripts (ie. netmount, ntp-client etc.) being executed before the network interface is able to be used.
Comment 2 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2009-12-21 23:32:24 UTC
I think you are looking for this:  

# Do we allow any started service in the runlevel to satisfy the depedency
# or do we want all of them regardless of state? For example, if net.eth0
# and net.eth1 are in the default runlevel then with rc_depend_strict="NO"
# both will be started, but services that depend on 'net' will work if either
# one comes up. With rc_depend_strict="YES" we would require them both to
# come up.
rc_depend_strict="YES"
Comment 3 Rick Harris 2010-05-30 05:23:32 UTC
(In reply to comment #2)
No, please re-read.

Further to this 'net.lo' is fulfilling the 'need net' dependency.
This is causing the same breakage.

An example on how to test:
1. Stop all net scripts (net.lo, net.eth0, net.wlan0)
2. Start a service that has the 'need net' depenency
3. Watch the fail

# /etc/init.d/ntp-client start
 * Bringing up interface lo
 *   127.0.0.1/8 ...                                                                                                                                                          [ ok ]
 *   Adding routes
 *     127.0.0.0/8 via 127.0.0.1 ...                                                                                                                                          [ ok ]
 * Setting clock via the NTP client 'ntpdate' ...
Name server cannot be used, exiting * Failed to set clock
Comment 4 William Hubbs gentoo-dev 2016-07-05 19:41:57 UTC
This bug is an example of the flaws in the net dependency, and imo, why
we should move away from it. [1]

[1] https://blog.flameeyes.eu/2012/10/may-i-have-a-network-connection-please