Re: Bug#1108899: dhcpcd-base: returns to post-up / shell before iface is ready
(@all please keep me in Cc, d-devel is too high-volume to subscribe)
Hi Daniel,
>Unfortunately dhcpcd-base breaks most assumptions :D.
this is… sad. Thanks, again, for working on this and for writing
so detailled about it.
>I assume you're talking about IPv4-LL? I'm disabling that from ifupdown
>now so a new option to neutralize it shouldnt be needed going forward.
Nice!
Although, you wrote…
> - inet6 auto has accept_ra=2 by default (which is questionable IMO),
> - inet6 dhcp has accept_ra=1.
> - inet6 static has accpet_ra=0.
… but there’s a fourth: just “inet dhcp” and no inet6 stanza,
which should also continue to operate with accept_ra=1, unless
changed by the user.
That’s the one I use in my “uncomplicated” setups, and the one
I expect to do the following:
- configure link-local address based on MAC EUI64
- let the kernel listen to rtadvd on the LAN and apply its config
(I’ve been bitten by ifup/ifdown issues when listing both inet
and inet6 for the same interface in the past.)
I’ve never seen inet6 auto used anywhere, only inet6 static (and
I’ve not personally encountered inet6 dhcp yet, and given rtadvd
and rtsol work, I don’t quite see the use for most networks).
For “inet6 static” I expect it to set up the link-local address
and the one given in address and gateway, if any, and not do rtsol.
>I learned ifupdown actually has an established `inet ipv4ll` method
>which would have been the right integration point for controlling this.
Ah, good.
>> Thanks for caring. I’ll be available for testing that (on a trixie
>> setup so with extra effort), if needed.
>
>See "Finishing deprecation of isc-dhcp-client in ifupdown" on d-devel with
>rationale and code https://lists.debian.org/debian-devel/2025/10/msg00201.html.
So, basically this?
>Proposed ifupdown unstable upload:
> [17]https://salsa.debian.org/debian/ifupdown/-/merge_requests/28
I can give this a spin on trixie. If I understood correctly from
the threads, I can revert the /etc/dhcpcf.conf change…
# Generate SLAAC address using the Hardware Address of the interface
-#slaac hwaddr
+slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
-slaac private
+#slaac private
… with this, as ifupdown handles it, right?
While there, I do have more questions related to it.
+option ntp_servers
Where would that be handled? If I wanted to, where do I have
to look to write integration for this for? (I use a custom
OpenNTPD packaging.)
+# hands off
+nohook resolv.conf, hostname, timezone, lookup-hostname
Is there a way to control this from ifupdown (for both ISC
and dhcpcd)?
>In unstable dhcpcd.service starts After=networking.service (ifup) meaning
>it triggers this conflict reproducibly. In Trixie no Before/After on
>networking is declared so the conflict will happen non-deterministically --
>oh joy.
Oh wow. So, note taken, do not install the dhcpcd package (let’s hope
nothing Recommends it).
Note that it could also be started from /etc/init.d/dhcpcd, so
ordering there also needs to be correct.
>That leaves us to think about what to do about current and future Trixie
>users: Retract the isc-dhcp-client deprecation? Fix it all in a stable
>update?
Likely not going to happen, as it has no security support.
(But, good to know that for systems with more complex networking
setups that are remote (thus hard to fix if somethign goes wrong)
I can still install isc-dhcp-client and keep dhcpcd-base away and
things continue to work… for now. IIUC?)
When I test your branch, did you also address the issue of, again
with a config just saying “iface eth0 inet dhcp” (no inet6), plus
wireless-* and wpa-* for WLAN as needed, that…
- I expect to not be assigned a Microsoft address; rather, either
an address from a DHCP server with much waiting or no address
and default route at all
- I expect the address and default gateway to be usable for both
post-up scripts and commands executed immediately after ifup
returns, which is currently not the case (I have to add a manual
five-second-or-so sleep)
(“expect” here does not mean “I demand the maintainers do this
immediately”, I use it with the meaning “this is how things work
in older releases, so from the principle of least surprise this
is what I, as user, expect from newer releases”)
THanks in advance,
//Thorsten
--
Thorsten Glaser
Linux / Unix Developer
Tel.: +49 160 91168501
E-Mail: tglaser@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / https://www.b1-systems.de/
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537
Reply to: