Message ID | 4861861e-1017-1596-e5bb-88f80c967971@jacknife.org |
---|---|
State | Not Applicable |
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4JWfTS3JYNz3wcH for <patchwork@web04.haj.ipfire.org>; Sun, 9 Jan 2022 01:27:40 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4JWfTR0Qwxz1VR; Sun, 9 Jan 2022 01:27:39 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4JWfTQ6P8pz2yqZ; Sun, 9 Jan 2022 01:27:38 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4JWfTP5wmwz2xxk for <development@lists.ipfire.org>; Sun, 9 Jan 2022 01:27:37 +0000 (UTC) Received: from pos (medynski.ca [24.222.224.134]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384) (Client did not present a certificate) by mail01.ipfire.org (Postfix) with ESMTPS id 4JWfTN5NjqzWy for <development@lists.ipfire.org>; Sun, 9 Jan 2022 01:27:36 +0000 (UTC) Received: from host-76-11-66-195.public.eastlink.ca ([76.11.66.195]:47202 helo=jacknife.org) by pos with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <spencer@jacknife.org>) id 1n6Mzb-0000QC-Hm for development@lists.ipfire.org; Sat, 08 Jan 2022 21:27:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=jacknife.org; s=exim; h=Content-Transfer-Encoding:Content-Type:Subject:From :To:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ddx8S39F7mF1baEU/IQgMNeSozPFcj6VS74CImSSYY4=; b=BSwmc9aDGDcq87tKfbA2IaKJDv EWULnO8NbN9N4F67yG4hoTOADQY0/dBuloCkReeg8+M2YaMYLL0rx4lICAYlZaOkfYTmtjE+Z8Lqq bc9mccWjl32WShjd63nNnCmJ1rL6o5de/0PUrr9W9oAIpll2nluz3Rn4yfExKpQVKDy4=; Received: from smegma ([10.0.3.2]) by jacknife.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <spencer@jacknife.org>) id 1n6MzZ-0003Qa-Uq for development@lists.ipfire.org; Sat, 08 Jan 2022 21:27:30 -0400 Message-ID: <4861861e-1017-1596-e5bb-88f80c967971@jacknife.org> Date: Sat, 8 Jan 2022 21:27:28 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Thunderbird/96.0 To: development@lists.ipfire.org Content-Language: en-US From: Brad Spencer <spencer@jacknife.org> Subject: Keep trying DHCP on red0 if unavailable at boot Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.5 X-Spam-Score: -3.1 X-Spam-Score-Int: -30 ARC-Authentication-Results: i=1; mail01.ipfire.org; dkim=pass header.d=jacknife.org header.s=exim header.b=BSwmc9aD; spf=pass (mail01.ipfire.org: domain of spencer@jacknife.org designates 24.222.224.134 as permitted sender) smtp.mailfrom=spencer@jacknife.org; dmarc=pass (policy=none) header.from=jacknife.org ARC-Seal: i=1; s=202003rsa; d=lists.ipfire.org; t=1641691657; a=rsa-sha256; cv=none; b=FnkqqJwfpdUYgvmYeCiji4qY/yYxwimWuQx4dMw3aaXEg8q88YY86Mu7UDrKGpil3A2w1u hnZrj8stXMfDn7kk6hJ/rOEhSZGDkbiVMtnb2NV1OO9BkaNwp8gIwGLiZwtenFWSYEVVxl iyYppQSW0HqCFboInYnug3seowK0VExM7koTqbMf0BYH39Q8dcIyr+kxSOdU23LQoZ0CRP pj1Arfefa2Y4Taln3VTBtu9MHSLjjNZkKqHB+UVeSBRJwh6sd9nvf1fJoVRu12+Yt1tM2i 9BO3h4QbYAgJmoNAB5vqKfok90kR7umXoBiwt9gUxulJOujVKX+zMnCoNYhSZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ipfire.org; s=202003rsa; t=1641691657; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=Ddx8S39F7mF1baEU/IQgMNeSozPFcj6VS74CImSSYY4=; b=MWGo8fhn62/gXHTDJuG5MCkQ5MH0Rj7bskidZ3gfLel60zVWtr4wJqqlLgBG+n9yaJb6De O3Ry4XgODgMIVHSoUuxxogTKMAYuHHGv1zklPNCNPLzwUrWs0TCpdbqGFu/pOI4g9SXtPN ia/kBNNiskYCteO7SZ9OrAICPBlVEK14L4MSagZRc7zLfECydATrdSSJQZi3rwo2cpX0BQ VMBGpWavg4hxg1jwYyKrcPpPEE9LsdFzba2DOG2nSpJYQCM56cNMZ72zGGpFxuTNwZmLrq 298zHswCoAfAxIec/o4iq18L4gnRZ7+4n9BMwo7bVxLFqfc0TF0T+wVlACpbRw== X-Spamd-Result: default: False [0.74 / 11.00]; HFILTER_HELO_5(3.00)[pos]; BAYES_HAM(-0.55)[80.80%]; DMARC_POLICY_ALLOW(-0.50)[jacknife.org,none]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[24.222.224.134:from]; R_DKIM_ALLOW(-0.20)[jacknife.org:s=exim]; R_SPF_ALLOW(-0.20)[+a:medynski.ca]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[jacknife.org:+]; ASN(0.00)[asn:11260, ipnet:24.222.224.0/20, country:CA]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_SIGNED(0.00)[lists.ipfire.org:s=202003rsa:i=1]; TO_DN_NONE(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[76.11.66.195:received] Authentication-Results: mail01.ipfire.org; dkim=pass header.d=jacknife.org header.s=exim header.b=BSwmc9aD; spf=pass (mail01.ipfire.org: domain of spencer@jacknife.org designates 24.222.224.134 as permitted sender) smtp.mailfrom=spencer@jacknife.org; dmarc=pass (policy=none) header.from=jacknife.org X-Rspamd-Queue-Id: 4JWfTN5NjqzWy X-Rspamd-Server: mail01.haj.ipfire.org X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
Keep trying DHCP on red0 if unavailable at boot
|
|
Commit Message
Brad Spencer
Jan. 9, 2022, 1:27 a.m. UTC
I had a failure today on my new ipfire installation that didn't survive the same kind of outage that my hand-made Debian-based firewall box had survived many times in the past: a power failure and restoration. In the community pages, I picked up an existing discussion and discussed the scenario in detail. I won't repeat that discussion here, but it was suggested that I post to this list and work towards an upstream change. https://community.ipfire.org/t/dhcp-client-on-red0-wont-reassign-ip-upon-reconnection/2455/26?u=spencer I won't repeat all the details of how I discovered this, but allow me to summarize the small changes I made. (See the community post and followups there for full details.) Basically, when ipfire boots and DHCP on red doesn't provide an address, dhcpcd times out after 60 seconds and then stops trying and nothing makes it try again. This leaves the green network up (good!) but the red network completely dead until someone reboots ipfire (or takes some other steps that re-trigger a start of dhcpcd). My simple repair so far has been: 1. Edit /etc/init.d/networking/functions.network to start dhcpcd in the background with no timeout. (Be sure to include that last space inside the quotes!) 2. For my testing, I also set ntp's ENABLESETONBOOT in /var/ipfire/time/settings to off (aka “Force setting the system clock on boot”) because it sits in a loop waiting for red0 to come up otherwise! At the time, I didn't notice that the loop in /etc/init.d/ntp stops after a minute, but nonetheless, it was handy to turn it off while testing :) So, I _think_ only the first change is necessary. All of the testing I did so far seems to indicate that, provided I don't have rules that explicitly mention the red0 IP address, all works well when the lease is acquired, or even when the lease changes the IP unexpectedly. Is a change like this something that could become part of ipfire? Thanks for making ipfire! I'm impressed so far.
Comments
I've had dhcp do that to me and it doesn't take a power failure but a downed isp will do.
My solution is to have a script run every 5 minutes to try again and after an hour reboot ipfire again.
My desktop just died and I'm rebuilding it but I can post that script if it's helpful.
Get BlueMail for Android
-------- Original Message --------
From: Brad Spencer <spencer@jacknife.org>
Sent: Sat Jan 08 20:27:28 EST 2022
To: development@lists.ipfire.org
Subject: Keep trying DHCP on red0 if unavailable at boot
I had a failure today on my new ipfire installation that didn't survive
the same kind of outage that my hand-made Debian-based firewall box had
survived many times in the past: a power failure and restoration.
In the community pages, I picked up an existing discussion and discussed
the scenario in detail. I won't repeat that discussion here, but it was
suggested that I post to this list and work towards an upstream change.
https://community.ipfire.org/t/dhcp-client-on-red0-wont-reassign-ip-upon-reconnection/2455/26?u=spencer
I won't repeat all the details of how I discovered this, but allow me to
summarize the small changes I made. (See the community post and
followups there for full details.)
Basically, when ipfire boots and DHCP on red doesn't provide an address,
dhcpcd times out after 60 seconds and then stops trying and nothing
makes it try again. This leaves the green network up (good!) but the
red network completely dead until someone reboots ipfire (or takes some
other steps that re-trigger a start of dhcpcd).
My simple repair so far has been:
1. Edit /etc/init.d/networking/functions.network to start dhcpcd in the
background with no timeout.
--- /root/functions.network.orig 2022-01-08 16:26:02.956856033 -0400
+++ functions.network 2022-01-08 21:07:28.617170885 -0400
@@ -56,7 +56,7 @@
# This function will start a dhcpcd on a speciefied device.
local device="$1"
- local dhcp_start=""
+ local dhcp_start="--timeout 0 --background "
boot_mesg -n "Starting dhcpcd on the ${device} interface..."
(Be sure to include that last space inside the quotes!)
2. For my testing, I also set ntp's ENABLESETONBOOT in
/var/ipfire/time/settings to off (aka “Force setting the system clock on
boot”) because it sits in a loop waiting for red0 to come up otherwise!
At the time, I didn't notice that the loop in /etc/init.d/ntp stops
after a minute, but nonetheless, it was handy to turn it off while
testing :) So, I _think_ only the first change is necessary.
All of the testing I did so far seems to indicate that, provided I don't
have rules that explicitly mention the red0 IP address, all works well
when the lease is acquired, or even when the lease changes the IP
unexpectedly.
Is a change like this something that could become part of ipfire?
Thanks for making ipfire! I'm impressed so far.
On 1/8/2022 10:03 PM, Jose Dias wrote: > I've had dhcp do that to me and it doesn't take a power failure but a > downed isp will do. > > My solution is to have a script run every 5 minutes to try again and > after an hour reboot ipfire again. > > My desktop just died and I'm rebuilding it but I can post that script > if it's helpful. Yes, I agree. In the community post I linked to, I tried to explain details failure. With my change to its startup arguments, I've been able to demonstrate that even if dhcpcd is unable to obtain an initial DHCP lease at boot, ipfire's boot sequence is not blocked, and dhcpcd does correctly keep retrying for longer than 60 seconds, and that ipfire reacts correctly when an IP is leased. See If you're interested, you can see my most recent followup in the community: https://community.ipfire.org/t/dhcp-client-on-red0-wont-reassign-ip-upon-reconnection/2455/38?u=spencer So, I'm going to try this instead of rebooting. The retries are frequent and cheap, and other (local) ipfire services remain available the whole time. Thanks for the offer!
Hi, thanks for getting in touch. The behaviour you described is tracked in bug #10813. I am currently working on a clean solution for this and bug #11502 but this takes time. The scripts involved in this are rather old (2007) which makes the fix more of a rewrite. You can see my progress here: https://git.ipfire.org/?p=people/jschlag/ipfire-2.x.git;a=shortlog;h=refs/heads/improve_network_startup As this needs a very good test a will reach out to the list when i have an iso image with all necessary changes. Greetings Jonatan > Am 09.01.2022 um 04:04 schrieb Brad Spencer <spencer@jacknife.org>: > > On 1/8/2022 10:03 PM, Jose Dias wrote: >> I've had dhcp do that to me and it doesn't take a power failure but a downed isp will do. >> >> My solution is to have a script run every 5 minutes to try again and after an hour reboot ipfire again. >> >> My desktop just died and I'm rebuilding it but I can post that script if it's helpful. > > Yes, I agree. In the community post I linked to, I tried to explain details failure. > > With my change to its startup arguments, I've been able to demonstrate that even if dhcpcd is unable to obtain an initial DHCP lease at boot, ipfire's boot sequence is not blocked, and dhcpcd does correctly keep retrying for longer than 60 seconds, and that ipfire reacts correctly when an IP is leased. See > > If you're interested, you can see my most recent followup in the community: https://community.ipfire.org/t/dhcp-client-on-red0-wont-reassign-ip-upon-reconnection/2455/38?u=spencer > > So, I'm going to try this instead of rebooting. The retries are frequent and cheap, and other (local) ipfire services remain available the whole time. > > Thanks for the offer! > > -- > Brad Spencer >
This is what I use. It actually runs out of /etc/fcron.hourly . The way it works for me, it'll keep trying to get an IP and if after 15 cycles it still doesn't have an IP then it reboots. Rebooting has no impact on dhcp on green as lease times will withstand a reboot. [root@harold fcron.hourly]# cat /etc/fcron.hourly/monitor_red_device.sh #!/bin/sh # set -vx SLEEP=30s DEV=red0 CYCLES=15 IPLOST=0 for c in `seq 1 $CYCLES` ; do # get ip address from external device, default red0 IP= IP=`ip address show dev ${DEV} | grep inet | awk '{print $2}'` echo IP=${IP} # if we got an ip then exit if [ -n "${IP}" ] ; then if [ ${IPLOST} -eq 0 ] ; then logger -t ipfire "IP= ${IP}" else logger -t ipfire "IP= ${IP} reaquired." fi exit 0 fi IPLOST=1 logger -t ipfire 'IP lost' # we don't have an IP address. wait a minute sleep ${SLEEP} /etc/init.d/networking/red stop ${DEV} sleep ${SLEEP} /etc/init.d/networking/red start ${DEV} sleep ${SLEEP} done logger -t ipfire 'IP not aquired. Rebooting.' # if we reach this far then we might as well restart telinit 6 -----Original Message----- From: Jonatan Schlag [mailto:jonatan.schlag@ipfire.org] Sent: Sun 1/9/2022 10:32 AM To: Brad Spencer Cc: Jose A. Dias; IPFire Development Subject: Re: Keep trying DHCP on red0 if unavailable at boot Hi, thanks for getting in touch. The behaviour you described is tracked in bug #10813. I am currently working on a clean solution for this and bug #11502 but this takes time. The scripts involved in this are rather old (2007) which makes the fix more of a rewrite. You can see my progress here: https://git.ipfire.org/?p=people/jschlag/ipfire-2.x.git;a=shortlog;h=refs/heads/improve_network_startup As this needs a very good test a will reach out to the list when i have an iso image with all necessary changes. Greetings Jonatan > Am 09.01.2022 um 04:04 schrieb Brad Spencer <spencer@jacknife.org>: > > ?On 1/8/2022 10:03 PM, Jose Dias wrote: >> I've had dhcp do that to me and it doesn't take a power failure but a downed isp will do. >> >> My solution is to have a script run every 5 minutes to try again and after an hour reboot ipfire again. >> >> My desktop just died and I'm rebuilding it but I can post that script if it's helpful. > > Yes, I agree. In the community post I linked to, I tried to explain details failure. > > With my change to its startup arguments, I've been able to demonstrate that even if dhcpcd is unable to obtain an initial DHCP lease at boot, ipfire's boot sequence is not blocked, and dhcpcd does correctly keep retrying for longer than 60 seconds, and that ipfire reacts correctly when an IP is leased. See > > If you're interested, you can see my most recent followup in the community: https://community.ipfire.org/t/dhcp-client-on-red0-wont-reassign-ip-upon-reconnection/2455/38?u=spencer > > So, I'm going to try this instead of rebooting. The retries are frequent and cheap, and other (local) ipfire services remain available the whole time. > > Thanks for the offer! > > -- > Brad Spencer >
Well, Rogers (my ISP) does not disappoint in this regard. They disappoint in other ways, but down time they are producing. This is what the logs show for today. This is from the IPFire section of the System Logs. I lost the IP at around at about 10:30 local time. I did some maintenance while it was out and then I let it cycle through. The only change I've made in the script below was to use CYCLES=18 to let it run a couple more times in the hour. This is rough but it gets around the bug for how. From: Development <development-bounces@lists.ipfire.org> On Behalf Of Jose A. Dias Sent: Sunday, January 9, 2022 4:02 PM To: Jonatan Schlag <jonatan.schlag@ipfire.org>; Brad Spencer <spencer@jacknife.org> Cc: IPFire Development <development@lists.ipfire.org> Subject: RE: Keep trying DHCP on red0 if unavailable at boot This is what I use. It actually runs out of /etc/fcron.hourly . The way it works for me, it'll keep trying to get an IP and if after 15 cycles it still doesn't have an IP then it reboots. Rebooting has no impact on dhcp on green as lease times will withstand a reboot. [root@harold fcron.hourly]# cat /etc/fcron.hourly/monitor_red_device.sh #!/bin/sh # set -vx SLEEP=30s DEV=red0 CYCLES=15 IPLOST=0 for c in `seq 1 $CYCLES` ; do # get ip address from external device, default red0 IP= IP=`ip address show dev ${DEV} | grep inet | awk '{print $2}'` echo IP=${IP} # if we got an ip then exit if [ -n "${IP}" ] ; then if [ ${IPLOST} -eq 0 ] ; then logger -t ipfire "IP= ${IP}" else logger -t ipfire "IP= ${IP} reaquired." fi exit 0 fi IPLOST=1 logger -t ipfire 'IP lost' # we don't have an IP address. wait a minute sleep ${SLEEP} /etc/init.d/networking/red stop ${DEV} sleep ${SLEEP} /etc/init.d/networking/red start ${DEV} sleep ${SLEEP} done logger -t ipfire 'IP not aquired. Rebooting.' # if we reach this far then we might as well restart telinit 6 -----Original Message----- From: Jonatan Schlag [mailto:jonatan.schlag@ipfire.org] Sent: Sun 1/9/2022 10:32 AM To: Brad Spencer Cc: Jose A. Dias; IPFire Development Subject: Re: Keep trying DHCP on red0 if unavailable at boot Hi, thanks for getting in touch. The behaviour you described is tracked in bug #10813. I am currently working on a clean solution for this and bug #11502 but this takes time. The scripts involved in this are rather old (2007) which makes the fix more of a rewrite. You can see my progress here: https://git.ipfire.org/?p=people/jschlag/ipfire-2.x.git;a=shortlog;h=refs/he ads/improve_network_startup As this needs a very good test a will reach out to the list when i have an iso image with all necessary changes. Greetings Jonatan > Am 09.01.2022 um 04:04 schrieb Brad Spencer <spencer@jacknife.org <mailto:spencer@jacknife.org> >: > > ?On 1/8/2022 10:03 PM, Jose Dias wrote: >> I've had dhcp do that to me and it doesn't take a power failure but a downed isp will do. >> >> My solution is to have a script run every 5 minutes to try again and after an hour reboot ipfire again. >> >> My desktop just died and I'm rebuilding it but I can post that script if it's helpful. > > Yes, I agree. In the community post I linked to, I tried to explain details failure. > > With my change to its startup arguments, I've been able to demonstrate that even if dhcpcd is unable to obtain an initial DHCP lease at boot, ipfire's boot sequence is not blocked, and dhcpcd does correctly keep retrying for longer than 60 seconds, and that ipfire reacts correctly when an IP is leased. See > > If you're interested, you can see my most recent followup in the community: https://community.ipfire.org/t/dhcp-client-on-red0-wont-reassign-ip-upon-rec onnection/2455/38?u=spencer > > So, I'm going to try this instead of rebooting. The retries are frequent and cheap, and other (local) ipfire services remain available the whole time. > > Thanks for the offer! > > -- > Brad Spencer >
--- /root/functions.network.orig 2022-01-08 16:26:02.956856033 -0400 +++ functions.network 2022-01-08 21:07:28.617170885 -0400 @@ -56,7 +56,7 @@ # This function will start a dhcpcd on a speciefied device. local device="$1" - local dhcp_start="" + local dhcp_start="--timeout 0 --background " boot_mesg -n "Starting dhcpcd on the ${device} interface..."