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 [thread overview]
Message-ID: <4861861e-1017-1596-e5bb-88f80c967971@jacknife.org> (raw)
[-- 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
next reply other threads:[~2022-01-09 1:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-09 1:27 Brad Spencer [this message]
[not found] <828db493-9cab-4eee-8e70-04fea6b18ca2@diaslan.com>
2022-01-09 3:04 ` Brad Spencer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4861861e-1017-1596-e5bb-88f80c967971@jacknife.org \
--to=spencer@jacknife.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox