2022-07-03

Refactoring Debian's dhcpcd packaging

Given news that ISC's DHCP suite is getting deprecated by upstream and seeing how dhclient has never worked properly for DHCPv6, I decided to look into alternatives. ISC itself recommends Roy Maple's dhcpcd as a migration path. Sadly, Debian's package had been left unattended for a good 2 years. After refactoring the packaging, updating to the latest upstream and performing one NMU, I decided to adopt the package.

Numerous issues were exposed in the process:

  • Upstream's ./configure makes BSD assumptions. No harm done, but still...
  • Upstream's ./configure is broken. --prefix does not propagate to all components. For instance, I had to manually specify the full path for manual pages. Patches are welcome.
  • Debian had implemented custom exit hooks for all its NTP packages. Since then, upstream has implemented this in a much more concise way. All that's missing upstream is support for timesyncd. Patches are welcome.
  • I'm still undecided on whether --prefix should assume / or /usr for networking binaries on a Debian system. Feedback is welcome.
  • The previous maintainer had implemented plenty of transitional measures in maintainer scripts such as symbolically linking /sbin/dhcpcd and /usr/sbin/dhcpcd. Most of this can probably be removed, but I haven't gotten around verifying this. Feedback and patches are welcome.
  • The previous maintainer had created an init.d script and systemd unit. Both of these interfere with launching dhcpcd using ifupdown via /etc/network/interfaces which I really need for configuring a router for IPv4 MASQ and IPv6 bridge. I solved this by putting them in a separate package and shipping the rest via a new binary target called dhcpcd-base along a logic similar to dnsmasq.
  • DHCPv6 Prefix Delegation mysteriously reports enp4s0: no global addresses for default route after a reboot. Yet if I manually restart the interface, none of this appears. Help debuging this is welcome.
  • Support for Predictable Interface Names was missing because Debian's package didn't Build-Depends on libudev-dev. Fixed.
  • Support for priviledge separation was missing because Debian's package did not ./configure this or create a system user for this. Fixed.
  • I am pondering moving the Debian package out of the dhcpcd5 namespace back into the dhcpcd namespace. The 5 was the result of an upstream fork that happened a long time ago and the original dhcpcd package no longer is in the Debian archive. Feedback is welcome on whether this would be desirable.

The key advantage of dhcpcd over dhclient is that works as a dual-stack DHCP client by design. With privilege separation enabled, this means separate child processes handling IPv4 and IPv6 configuration and passing the received information to the parent process to configure networking and update /etc/resolv.conf with nameservers for both stacks. Additionally, /etc/network/interfaces no longer needs separate inet and inet6 lines for each DHCP interface, which makes for much cleaner configuration files.

A secondary advantage is that the dual-stack includes built-in fallback to Bonjour for IPv4 and SLAAC for IPv6. Basically, unless the interface needs a static IP address, this client handles network configuration in a smart and transparent way.

A third advantage is built-in support for DHCPv6 Prefix Delegation. Enabling this requires just two lines in the configuration file.

In the long run, I feel that dhcpcd-base should probably replace isc-dhcp-client as the default DHCP client with priority Important. Adequate IPv6 support should come out of the box on a standard Debian installation, yet dhclient never got around implementing that properly.

2 comments:

Alexander E. Patrakov said...

Yes, dhcpcd is great. It is lightweight and full of correctly-implemented features. Yet this project, according to the git commit log, is mostly a one-man show. Given this and the fact that the author has cancer, I don't think that it's a safe solution long-term as one of the base components of Debian.

Martin-Éric said...

ISC DHCP also is mostly a one-man show. Both projects are hosted via a publicly hoosted Git repository and can easily be forked. The key point here is that ISC's code has become a mess while dhcpcd is a clean implementation.