Keep trying DHCP on red0 if unavailable at boot

Keep trying DHCP on red0 if unavailable at boot

[Brad Spencer]

[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]

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.

-- 
Brad Spencer

Re: Keep trying DHCP on red0 if unavailable at boot

[Brad Spencer]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

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