I think I’ve solved the problem of having ipfire boot with a “dead forever” red0 interface when DHCP doesn’t serve an address within the 30-60 second timeout of dhcpcd’s initial attempt.
Steps:
- 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!)
- Set
ntp’s ENABLESETONBOOT in /var/ipfire/time/settings to off (aka “Force setting the system clock on boot”) because it sits in a blocking loop waiting for red0 to come up otherwise! 
I tested all of this with ipfire running in a VM with interface I can completely control.
Boot with cable unplugged:
Jan 8 20:37:34 ipfire dhcpcd[1579]: dhcpcd-9.4.1 starting
Jan 8 20:37:34 ipfire dhcpcd[1582]: DUID 00:04:24:70:f1:41:01:82:d0:4b:b5:09:ae:87:60:d0:15:54
Jan 8 20:37:35 ipfire dhcpcd[1582]: red0: waiting for carrier
System comes up fine with RED “Connecting…”.
Connect the cable after boot:
Jan 8 20:41:05 ipfire dhcpcd[1582]: red0: carrier acquired
Jan 8 20:41:05 ipfire dhcpcd[1582]: red0: IAID 27:40:11:d7
Jan 8 20:41:05 ipfire dhcpcd[1582]: red0: adding address fe80::a00:27ff:fe40:11d7
Jan 8 20:41:05 ipfire dhcpcd[1582]: ipv6_addaddr1: Permission denied
Jan 8 20:41:05 ipfire dhcpcd[1582]: red0: soliciting an IPv6 router
Jan 8 20:41:07 ipfire dhcpcd[1582]: red0: rebinding lease of 10.0.3.88
Jan 8 20:41:07 ipfire dhcpcd[1582]: red0: probing address 10.0.3.88/24
Jan 8 20:41:11 ipfire dhcpcd.exe[2229]: red0 has been (re)configured with IP=10.0.3.88
Jan 8 20:41:12 ipfire unbound: [1449:0] info: service stopped (unbound 1.13.2).
Jan 8 20:41:12 ipfire unbound: [1449:0] info: server stats for thread 0: 22 queries, 6 answers from cache, 16 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Jan 8 20:41:12 ipfire unbound: [1449:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0
Jan 8 20:41:12 ipfire unbound: [1449:0] info: average recursion processing time 0.000000 sec
Jan 8 20:41:12 ipfire unbound: [1449:0] info: histogram of recursion processing times
Jan 8 20:41:12 ipfire unbound: [1449:0] info: [25%]=2.5e-07 median[50%]=5e-07 [75%]=7.5e-07
Jan 8 20:41:12 ipfire unbound: [1449:0] info: lower(secs) upper(secs) recursions
Jan 8 20:41:12 ipfire unbound: [1449:0] info: 0.000000 0.000001 16
Jan 8 20:41:12 ipfire unbound: [1449:0] notice: Restart of unbound 1.13.2.
Jan 8 20:41:12 ipfire unbound: [1449:0] notice: init module 0: validator
Jan 8 20:41:12 ipfire unbound: [1449:0] notice: init module 1: iterator
Jan 8 20:41:12 ipfire unbound: [1449:0] info: start of service (unbound 1.13.2).
Jan 8 20:41:12 ipfire unbound: [1449:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Jan 8 20:41:13 ipfire ntpd[1691]: Listen normally on 4 red0 10.0.3.88:123
Jan 8 20:41:13 ipfire ntpd[1691]: new interface(s) found: waking up resolver
System status now reports “Connected” with the right IP.
Next, I changed the DHCP server that issued red0’s IP address while the system was running and forced a refresh. (This doesn’t really happen without the lease expiring, but it was a handy way to test that things can handle an IP change.)
Jan 8 20:56:02 ipfire dhcpcd[2625]: sending signal HUP to pid 1556
Jan 8 20:56:02 ipfire dhcpcd[1557]: received SIGHUP, rebinding
Jan 8 20:56:02 ipfire dhcpcd[1557]: red0: IAID 27:40:11:d7
Jan 8 20:56:03 ipfire dhcpcd[1557]: red0: soliciting an IPv6 router
Jan 8 20:56:04 ipfire dhcpcd[1557]: red0: rebinding lease of 10.0.3.88
Jan 8 20:56:04 ipfire dhcpcd[1557]: red0: NAK: requested address is incorrect from 10.0.3.250
Jan 8 20:56:04 ipfire dhcpcd[1557]: red0: message: requested address is incorrect
Jan 8 20:56:04 ipfire dhcpcd[1557]: red0: deleting route to 10.0.3.0/24
Jan 8 20:56:04 ipfire dhcpcd[1557]: red0: deleting default route via 10.0.3.250
Jan 8 20:56:04 ipfire dhcpcd.exe[2638]: red0 has been brought down (NAK)
Jan 8 20:56:04 ipfire dhcpcd[1557]: red0: soliciting a DHCP lease
Jan 8 20:56:04 ipfire dhcpcd[1557]: red0: offered 10.0.3.98 from 10.0.3.250
Jan 8 20:56:04 ipfire dhcpcd[1557]: red0: probing address 10.0.3.98/24
Jan 8 20:56:05 ipfire ntpd[1668]: Deleting interface #4 red0, 10.0.3.88#123, interface stats: received=0, sent=0, dropped=0, active_time=206 secs
Jan 8 20:56:08 ipfire dhcpcd[1557]: red0: leased 10.0.3.98 for 3600 seconds
Jan 8 20:56:08 ipfire dhcpcd[1557]: red0: adding route to 10.0.3.0/24
Jan 8 20:56:08 ipfire dhcpcd[1557]: red0: adding default route via 10.0.3.250
Jan 8 20:56:08 ipfire dhcpcd.exe[2803]: red0 has been (re)configured with IP=10.0.3.98
Jan 8 20:56:09 ipfire unbound: [1424:0] info: service stopped (unbound 1.13.2).
Jan 8 20:56:09 ipfire unbound: [1424:0] info: server stats for thread 0: 5 queries, 1 answers from cache, 4 recursions, 0 prefetch, 0 rejected by ip ratelimiting
Jan 8 20:56:09 ipfire unbound: [1424:0] info: server stats for thread 0: requestlist max 1 avg 0.25 exceeded 0 jostled 0
Jan 8 20:56:09 ipfire unbound: [1424:0] info: average recursion processing time 0.126770 sec
Jan 8 20:56:09 ipfire unbound: [1424:0] info: histogram of recursion processing times
Jan 8 20:56:09 ipfire unbound: [1424:0] info: [25%]=0.001536 median[50%]=0.002048 [75%]=0.131072
Jan 8 20:56:09 ipfire unbound: [1424:0] info: lower(secs) upper(secs) recursions
Jan 8 20:56:09 ipfire unbound: [1424:0] info: 0.001024 0.002048 2
Jan 8 20:56:09 ipfire unbound: [1424:0] info: 0.065536 0.131072 1
Jan 8 20:56:09 ipfire unbound: [1424:0] info: 0.262144 0.524288 1
Jan 8 20:56:09 ipfire unbound: [1424:0] notice: Restart of unbound 1.13.2.
Jan 8 20:56:09 ipfire unbound: [1424:0] notice: init module 0: validator
Jan 8 20:56:09 ipfire unbound: [1424:0] notice: init module 1: iterator
Jan 8 20:56:09 ipfire unbound: [1424:0] info: start of service (unbound 1.13.2).
Jan 8 20:56:09 ipfire unbound: [1424:0] info: generate keytag query _ta-4a5c-4f66. NULL IN
Jan 8 20:56:10 ipfire ntpd[1668]: Listen normally on 5 red0 10.0.3.98:123
Jan 8 20:56:10 ipfire ntpd[1668]: new interface(s) found: waking up resolver
And everything looks right. The status page says “Connected” and lists the new IP.
To be sure all was well, I did these tests with an arbitrary RED->GREEN port forward bound specifically to RED networks (vs. “any” network), and thus the iptables rules use the red0 interface, thus the rules still can be applied without an IP. (Of course, if I expect RED’s IP to change, I don’t write rules that specify it, but it was good to see that ipfire doesn’t artificially use the IP in its rules either.)
I’ll join the developer list and ask about this change there and see if folks are amenable to a change here.
Meanwhile, I’ll go make these changes on my real ipfire installation and “see what happens next time” 
If the modem cannot reach the CMTS it should go in ‘local mode’, handing out an IP of the ‘modem net’ ( 192.168.100.0/24 ) with an very short lease time <1min
In all my years running my setup, I’ve only seen my bridged modem act as a DHCP server once. I would only expect that to happen in specific failure modes, and then with the fast renew times, I would expect it to self-clear. To my network, including the ipfire box, that should be no different than any other IP address really assigned by my ISP, but without actual Internet access. So, when the real DHCP service becomes available over the bridge, ipfire’s DHCP client should renew on the next cycle, get the real IP, and all should work. No manual intervention required.
Thanks to everyone for the suggestions and help! I’ll report back if this solution turns out to not work well.
