Hi Simon, On Wed, Oct 22, 2025 at 10:34:05PM +0900, Simon Richter wrote: > > tl;dr: ifupdown + dhcpcd-base in Trixie is broken in all but the most > > defaultest configurations, consequently isc-dhcp-client deprecation is a > > wash. It's a mess. Lets fix it. > > Yay. *Yay* indeed :D. > The biggest obstacle I see is actually making sure at least one of ISC > dhcp-client or dhcpcd is installed when using DHCP. > > Would it make sense to make ifupdown prefer dhcpcd if both it and the ISC > client are installed, then make the ISC client package pull in dhcpcd? That was essentially the plan in my head, yeah. I expect ISC will get RMed so we can replace it with a metapackage that just pulls in dhcpcd-base. > > - [Independent control] over IPv6 and IPv4 operation from ifupdown is > > broken. A single `inet` stanza will enable both, so `inet6 static` also > > does SLAAC/DHCPv6. > > The default interface config has "accept_ra" enabled, so SLAAC is enabled as > soon as the link is up. Which METHOD are you talking about auto, dhcp, static, manual? The defaults vary. Another "yey" I found while working on this see the code ;-). - inet6 auto has accept_ra=2 by default (which is questionable IMO), - inet6 dhcp has accept_ra=1. - inet6 static has accpet_ra=0. > If we "fix" that, it will be about as controversial as systemd's decision > to drop into an emergency shell if a non-root filesystem fails to mount, > when the sysvinit script failed to pass the exit code along and just > continued booting. My implementation retains the previous behaviour with dhclient as best it can, accept_ra=1 being the exception for now. So I'm not sure what you mean exactly? > > - Non-deterministic [daemon conflics] between ifup's dhcpcd instances and > > dhcpcd.service may cause boot or renew problems. > > Horrible idea: can we build a systemd generator that creates units to > resolve these conflicts? dhcpcd.service and dhcpcd@.service can simply declare Before=networking.service and all is well AFAICT. No need for the big guns -- yet :-). The ordering is just the wrong way around in dhcpcd/unstable rn (After=networking.service). > > As a reminder: starting with Trixie dhcpcd-base is now Priority:important > > (#1038882) instead of isc-dhcp-client. AFACT this only affects new > > installations, not upgrades so we've split the userbase. > > The important change, I think, was changing the first preference in > ifupdown's Recommends field, but the effect is the same. Not sure either TBH. Point is I don't think this was the intended effect either way. Thinking about what to do if we ever want to change the default again in the future without similarly abusing dhcpcd-base: Do you think it would make sense to introduce a dhcp-client (meta)package? We could have the isc-dhcp-client transisional metapackage Depend on dhcp-client and that would Depend on dhcpcd-base in turn while ifupdown Recommends: dhcp-client. dhcp-client could ship a marker file or something else ifupdown can pick up from inet*.defn or just a up.d/down.d script -- though I'd have to think through the implications of potentially changing details of up/down ordering in that case. > > The dhcpd *package* additionally provides a system service that will start > > dhcpcd in dual-stack global manager mode at boot. It will bring UP most > > interfaces automatically with IPv4 DHCP, IPv4-LL and IPv6 SLAAC and/or > > Stateful DHCPv6 as appropriate, but regardless of ifupdown configuration or > > whether a per-iface instance is already running(!), see [daemon conflicts]. > > I think that is a bug in dhcpcd -- other tools make sure to ignore > interfaces configured through ifupdown. I tend to agree, but I think we can do one better and have the two packages interoperate cleanly instead of just avoiding each others interfaces -- that's what dhcpcd.sh should achive modulo the boot ordering problem. > As before, I fully expect a lot of installations to depend on this bug. > > > A dhcpcd patch could be suitable for Trixie even, but so far dhcpd's > > maintainer has refused to consider downstream changes -- else I'd have > > fixed this well before Trixie already :-]. Truth be told I'm pretty annoyed > > I had to spend more than a full blown focused work week on designing, > > implementing, documenting this hacky fix on the ifupdown side instead of > > spinning a 10 LoC dhcpcd patch in half an hour, but here we are. Ugh. > > FWIW, I think that kind of integration work is the job of a distribution, so > I'm totally fine shipping a patched package even if upstream does not accept > the patch. I think upstream would be aminable to all of this. The changes make sense purely from the perspective of dhcpcd's operation mode as far as I understand it after experimenting with it and reading the code for a solid week -- which may not be saying much for this beast, but hey ;-). One caveat is that the per-iface modes are going away in dhcpcd v11 according to upstream, so we're patching what's about to be dead code. However that's part of the reason I decided to go the extra mile and make this all work with global manager mode. This way assuming we ship the per-iface -> manager change to Trixie users we have a clean and easy upgrade path in Forky+ once dhcpcd v11 drops the other daemon modes. The good news is that much of the hairy stuff in dhcpcd.sh should also be able to go away once that happens. > We'd also need to define a conflict resolution policy for dhcpcd vs > systemd-networkd if we are touching dhcpcd. There is the ID_NET_MANAGED_BY udev property proposal from systemd land already if you haven't seen it yet. Eg. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1108124#5 has more links and dhcpcd has an upstream issue https://github.com/NetworkConfiguration/dhcpcd/issues/518. I haven't decided yet if that really fits into ifupdown's constraints. > My favourite policy would be > > 1. explicit configuration wins over autodetection > 2. clear hierarchy for the rest, documented in Debian Policy > > So, anyone autodetecting interfaces needs to consult either all the other > configuration files (which is bullshit, but doable), or we create another > interface between packages (e.g. /var/run/managed_interfaces) and document > it in Debian Policy. I would not feel confident deploying the latter in a > stable update, though. Yeah, this is all work for Forky IMO. For now I just want to stop the bleeding before more users try to migrate to dhcpcd-base and the broken configs ossify. Thanks, --Daniel <3
Attachment:
signature.asc
Description: PGP signature