Hi Thorsten,
(merging this back into the main thread)
On Wed, Oct 22, 2025 at 08:22:07PM +0200, Thorsten Glaser wrote:
> (@all please keep me in Cc, d-devel is too high-volume to subscribe)
>
> > - 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
Right. I don't explicitly reason about that configuration since kernel
defaults apply so it's just not really managed by ifupdown at this point,
other than ifdown having to make sure we restore sysctl defaults cleanly I
suppose.
Thinking about this some more I may consider requiring `inet6 auto` in the
future for this configuration, but not without a proper transition and
ample notice.
> (I’ve been bitten by ifup/ifdown issues when listing both inet
> and inet6 for the same interface in the past.)
Can you elaborate here?
> 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).
Strange, given that this is what d-i will produce by default -- if the
installation network has IPv6 RAs at least.
> 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.
Ofc.
> 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?
My ifupdown now overrides the --slaac config for the interface it's upping
so you can revert this to get a clean config or leave it, doesn't
matter. It'll work.
> 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.)
See dhcpcd-run-hooks(1). Unfortunately we don't have .d support there yet
see #1101003.
I'm considering running /etc/dhcp/dhclient-*-hooks from the equivalent
dhcpcd hooks. Not sure that would work in most cases, but given they both
(mostly) represent the DHCP/v6 state machines it may work out.
> +# hands off
> +nohook resolv.conf, hostname, timezone, lookup-hostname
>
> Is there a way to control this from ifupdown (for both ISC
> and dhcpcd)?
Not at the moment, no.
IMO if you need to make changes that deep it's alright to have to go to the
dhcp client config files to do it honestly, unless you disagree?
For example ideally resolv.conf integration really should just-work^TM
right without users having to disable it in the first place (also on my
TODO list) :D.
> >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).
$ curl http://ftp.debian.org/debian/dists/trixie/main/binary-amd64/Packages.gz | zcat | zgrep 'Recommends:.*dhcpcd'
Looks fine.
> Note that it could also be started from /etc/init.d/dhcpcd, so
> ordering there also needs to be correct.
Naturally, but I do think that should also be possible. I'm just not
familliar with sysvinit's ways.
> >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.
Well given that we've shipped isc-dhcp-client in Trixie already without
properly moving all users over that ship has kinda already sailed. Now we
have to support it. See #1106121.
If we remove the release-notes notice at least fewer users might try to
switch and consequently run into problems. Idk. if that'd really be a good
idea its just a thought.
> (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?)
Eeeeerm. Well. I've seen dhclient crash mysteriously after long runtime
leaving systems without IPs somehow. So that's not a sure bet
either. Honestly I have more confidence in dhcpcd to actually work
reliably, you just need to configure it in the right place and doublecheck
it's doing what you want until all this is fixed.
> 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)
Yeah, thats how things should look now. LMK if you see something different.
--Daniel
Attachment:
signature.asc
Description: PGP signature