From mboxrd@z Thu Jan  1 00:00:00 1970
From: Brad Spencer <spencer@jacknife.org>
To: development@lists.ipfire.org
Subject: Keep trying DHCP on red0 if unavailable at boot
Date: Sat, 08 Jan 2022 21:27:28 -0400
Message-ID: <4861861e-1017-1596-e5bb-88f80c967971@jacknife.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8049831735226598272=="
List-Id: <development.lists.ipfire.org>

--===============8049831735226598272==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I had a failure today on my new ipfire installation that didn't survive=20
the same kind of outage that my hand-made Debian-based firewall box had=20
survived many times in the past: a power failure and restoration.

In the community pages, I picked up an existing discussion and discussed=20
the scenario in detail.=C2=A0 I won't repeat that discussion here, but it was=
=20
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-reco=
nnection/2455/26?u=3Dspencer

I won't repeat all the details of how I discovered this, but allow me to=20
summarize the small changes I made.=C2=A0 (See the community post and=20
followups there for full details.)

Basically, when ipfire boots and DHCP on red doesn't provide an address,=20
dhcpcd times out after 60 seconds and then stops trying and nothing=20
makes it try again.=C2=A0 This leaves the green network up (good!) but the=20
red network completely dead until someone reboots ipfire (or takes some=20
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=20
background with no timeout.

--- /root/functions.network.orig=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 20=
22-01-08 16:26:02.956856033 -0400
+++ functions.network=C2=A0=C2=A0 2022-01-08 21:07:28.617170885 -0400
@@ -56,7 +56,7 @@
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # This function will start a dhcp=
cd on a speciefied device.

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 local device=3D"$1"
-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 local dhcp_start=3D""
+=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 local dhcp_start=3D"--timeout 0 --backg=
round "

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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=20
/var/ipfire/time/settings to off (aka =E2=80=9CForce setting the system clock=
 on=20
boot=E2=80=9D) because it sits in a loop waiting for red0 to come up otherwis=
e!

At the time, I didn't notice that the loop in /etc/init.d/ntp stops=20
after a minute, but nonetheless, it was handy to turn it off while=20
testing :)=C2=A0 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=20
have rules that explicitly mention the red0 IP address, all works well=20
when the lease is acquired, or even when the lease changes the IP=20
unexpectedly.

Is a change like this something that could become part of ipfire?

Thanks for making ipfire!=C2=A0 I'm impressed so far.

--=20
Brad Spencer


--===============8049831735226598272==--