dhcpcd-11 will remove the ability for a process per interface

[rsmarples]

The classical way of starting DHCP is saying "start DHCP on this interface" and you would get a process on the interface.
For a single interface system, or only running one DHCP process this works well - but cannot bind the unspecified address to a port as only one process can do this. So to work around, we bind the address we leased to a port. For DHCP this works well.

Enter IPv6. We have the same issues, just a lot more because we have many more addresses in play. You start with the LL address, and generally get one prefix from RA, which could translate into two addresses if using temporary addresses. You then have DHCPv6 addresses and maybe a Delegated Prefix if on a router which then goes into how ever many interfaces you're delegating to for an address as well. To make matters worse, for RA there is no address or port to bind to - so only one process gets then Router Announcements.

And then we have privsep - we need to launch a process per address just to listen to it because addresses can change and only root can bind to the port we need and we really don't want a root process listening to the port.

No, this is far too complicated in today's world and dhcpcd has catered to the likes of netifrc and ifup for as long as it can.

dhcpcd-11 will require starting as a service in the same way as apache, postfix or dnsmasq. We've been able to do this since dhcpcd-5 and I've been encouraging this since. So this should hardly be new, but it will now be a requirement.
dhcpcd-11 will likely have a much reduce set of commands from the command line, but the dhcpcd.conf file will remain unchanged.

Any commentary on these proposed changes are welcome.

[borkra]

The problem with that current dhcpcd in master mode has no ability to stop servicing Ethernet ports at runtime (Without restarting the daemon). Per port ip renew did not work either. The same goes for IPv6 there must be ability at runtime to enable/disable IPv6 on each port independently. Connectivity on other ports not suject to reconfiguration must not be lost.

[perkelix]

No, the correct action is not to modify ifupdown. It is to remove the separate inet6 stanza. Separate inet and inet6 stanza are remnants of trying to add support for the IPv6 stack onto an existing framework meant only for IPv4. Additionally, those separate inet6 stanza are only needed for static addresses. For everything else (except PD), the kernel self-configures IPv6.

[ktetzlaff]

@perkelix: Still no answer to my question regarding dhcpcd manager mode.

Separate inet and inet6 stanza are remnants of trying to add support for the IPv6 stack onto an existing framework meant only for IPv4.

I cannot find any reference to this in the ifupdown documentation. Where do you get your information from?

kernel self-configures IPv6

That might be true for SLAAC, but AFAIK not for stateful DHCPv6.

[perkelix]

Which still doesn't require a separate inet6 line since dhcpcd handles both stacks.

[rsmarples]

@ktetzlaff dhclient operates one instance per interface protocol. IIRC you cannot run dhclient for inet6 on more than one interface, or not reliably.
dhcpcd works around this .... but uses a lot more resources.

Where we want to go is one instance for all interfaces and protocols as that uses a lot less resources and is a lot easier to codify.
Due to this, all commands to dhcpcd have to be for one interface and all it's protocols in one hit. You can't say "do ipv6" in one call and "do ipv4" in another and expect the ipv6 to still be running.
In other words, you can no longer treat it as a like for like replacement to dhclient.

You can use manager mode (it was renamed from master) in any 9.x release onwards. Maybe even earlier, I forget.
Think of it like dbus - you start it as a system service and then apply an interface state to it as a whole, not in part.
We might allow part changes moving forwards, but it is what it is for now.

[ktetzlaff]

You can use manager mode (it was renamed from master) in any 9.x release onwards.

@rsmarples Ok, so again the question: How do I actually use manager mode?

Here's what I tried (see my earlier comment for details on environment and config):

1. ifdown -a
2. all interfaces down, no DHCP clients running
3. ip link set dev eth0 up
4. now, eth0 is in state up without any IP addresses
5. add denyinterfaces * to /etc/dhcpcd.conf
6. dhcpcd
7. this just starts dhcpcd in manager mode without configuring interfaces (verified by running ps -ef | grep dhcpcd) , still no IP addresses on eth0 (as expected)
8. dhcpcd eth0
9. this is where I expected that dhcpcd would configure eth0 with both IPv4 and IPv6 addresses, but it doesn't (nothing seems to happen apart from writing sending commands to dhcpcd process to stdout)

What is required (in step 8 or elsewhere) to make dhcpcd start the actual interface configuration on eth0 after being started in manager mode in step 6?

[rsmarples]

First pass at this here: https://github.com/NetworkConfiguration/dhcpcd/tree/manager_only
Seems to work fine and a lot of code has been removed.

Likely some issues and hopefully some more code can be removed as well.

[DanielG]

Hi Roy,

I don't think this is the right direction. I'd like to help fix whatever problems exist with the per-interface approach instead, but to do that we first have to be more specific about the problems that need addressing. From the above I get:

• RA ICMPv6 socket "only one process gets then RAs"
  I'm not aware of this limitation. I just tested on Linux and all IPPROTO_ICMPV6 raw sockets seem to receive all announcements so what is the problem?

• privsep

  • (too) many addresses to bind (and hence processes?)
    Have you considered the following architecture: A root process opens one socket per-IPPROTO, sends those to the one unprivileged process over unix socket (SCM_RIGHTS) and the root proc. answers requests to bind/unbind addrs on those socket in their stead (simply by keeping the FDs around)?

  • (source) address selection
    Would be redundant if the above works since only one socket exists. No?

I don't quite grock the current overall privsep design yet so perhaps you could elaborate on how things are done now?

--Daniel

[rsmarples]

The privsep model you describe is what is currently in place for manager mode.
manager -> network proxy (binds anyaddr:port and icmp6)

For non manager mode (ie one specific interface) it goes like this:
manager -> privileged proxy -> per address proxy:port
manager -> network proxy (icmp6)
I am proposing to remove this in favour of solely the above - we currently have both models.

Currently the only functionality lost I think is test mode (i think pointless now we have the noconfigure option, the effect is the same aside we don't exit). We might lose timeout as well.

I am curious though - what makes you think this is not the right direction? Can you justify the use of a lot more system resources and guesswork on which address to send from to support this model?

[DanielG]

I am curious though - what makes you think this is not the right direction?

My concern is that we will loose (admittedly niche) functionality, such as integration with ifupdown and similar tools, loosing test mode is another example I care about and making VRF support harder to implement is another. I get that per-interface mode is currently broken so technically we're not loosing anything but that's something I intend to fix :)

Can you justify the use of a lot more system resources and guesswork on which address to send from to support this model?

I'm not trying to justify this I'm trying to understand why per-interface daemons would inherently have to be any different here? The only necessary "overhead" I can see is more processes, but that's not a clear cut advantage of your proposal either IMO.

The privsep model you describe is what is currently in place for manager mode. manager -> network proxy (binds anyaddr:port and icmp6)

Not exactly, currently there seem to be a number of unpriviledged processess talking to each other, but I just don't see the benefit over having a single unpriv. process (perhaps per-interface) even in manager mode? Since the security design (threat model etc.) aren't written down it's hard to say whether this is pure overkill or good design. This is something we ought to talk about in detail.

For non manager mode (ie one specific interface) it goes like this: manager -> privileged proxy -> per address proxy:port manager -> network proxy (icmp6)

I am proposing to remove this in favour of solely the above - we currently have both models.

I agree having two different code paths is undesirable, but from where I'm sitting applying a "one unpriv. process" per-interface model to manager mode seems like it should also work and wouldn't imply having to drop per-interface mode.

Currently the only functionality lost I think is test mode (i think pointless now we have the noconfigure option, the effect is the same aside we don't exit). We might lose timeout as well.

What about things like setting -script per-interface? Does that work with manager mode?

[rsmarples]

My concern is that we will loose (admittedly niche) functionality, such as integration with ifupdown and similar tools, loosing test mode is another example I care about and making VRF support harder to implement is another. I get that per-interface mode is currently broken so technically we're not loosing anything but that's something I intend to fix :)

There is the undocumented --noconfigure option which gives the same functionality as test, although you do lose the TEST reason in dhcpcd-run-hooks. This is actually better as TEST still uses DHCP leases on the server side so what we do is more clear.

I don't buy that VRF support is any harder. AFAIK it just uses a different routing table for routes from the interface?

Also, see the further down in this thread where @hpresnall has my proposed changes working with ifupdown-ng.

Can you justify the use of a lot more system resources and guesswork on which address to send from to support this model?

I'm not trying to justify this I'm trying to understand why per-interface daemons would inherently have to be any different here? The only necessary "overhead" I can see is more processes, but that's not a clear cut advantage of your proposal either IMO.

The privsep model you describe is what is currently in place for manager mode. manager -> network proxy (binds anyaddr:port and icmp6)

Not exactly, currently there seem to be a number of unpriviledged processess talking to each other, but I just don't see the benefit over having a single unpriv. process (perhaps per-interface) even in manager mode? Since the security design (threat model etc.) aren't written down it's hard to say whether this is pure overkill or good design. This is something we ought to talk about in detail.

Sure.
The manager process is completely isolated from any outside input bar signals.
So we proxy input from the outside to it via other processes.
Once each process is setup, privileges are dropped and per OS sand-boxing is installed.
On OpenBSD, the control proxy requires a slightly higher level of elevation than the others so it can accept new connections.
I think the network proxy could be rolled into the manager process, but that increases what the manager process could send if breached.
The network proxy performs validation of the messages it's about to send - ie what port it's going from/to.
Any breach is likely to happen in the manager process as that's where all the complexity is so we really limit what it can and cannot do.

Remember, this is a public facing process with the ability to alter anything as that's the nature of what we do.
We want to be very anally retentive here.

I agree having two different code paths is undesirable, but from where I'm sitting applying a "one unpriv. process" per-interface model to manager mode seems like it should also work and wouldn't imply having to drop per-interface mode.

We have the problem of the OS only allowing one process to bind an address:port tuple.
The unspecified address counts in this.

So the per interface solution is to bind to addresses on the interface.
As addresses come and go, the binding needs to be done by the privileged process.
This also introduces a new problem - which address do we send from when doing a L3 renew?
There is no guarantee that the address we should be using is to send from is the one we leased.
For example, DHCPv6 you could have many addresses and only one of them might reach the server we need to unicast to.
Sending has already been solved by using RAW sockets.

Solve the binding issue on all supported OS and then we can talk.

What about things like setting -script per-interface? Does that work with manager mode?

Yes

[hpresnall]

FYI, I have this mostly working in Alpine linux 3.19 with ifupdown-ng by making the following changes:

1. In /etc/init.d/dhcpcd, remove provide net and change before dns to before networking dns
2. Make sure dhcpcd is set to run at the boot run level, not default.
3. In /usr/libexec/ifupdown-ng/dhcp, change the start command to /sbin/dhcpcd -q -n $optargs $IFACE (adding -n). This makes ifup rebind instead of starting in non-manager mode. The stop function, for ifdown, already had -k in the args.

There may be a more subtle way to get dhcpcd to start before any interfaces are ifup'ed but the first 2 steps as brute force work well enough.

[ncopa]

I don't think this will work for Alpine. It would mean that the dhcpcd openrc service must run before ifup works if dhcpcd package is installed.

Another problem here is that ifupdown-ng and busybox's ifupdown support both dhcpcd, dhclient and udhcpc as backends.

Alpine linux also supports running dhcpcd as a "net" provider, without any ifupdown or any /etc/network/interfaces. (I have also considered using dhcpcd as the only network manager for alpine linux, but we also need something that can manage bridges and vlans - and we need backwards compatibility)

I think what we need to do is modify the {dhcp executor](https://github.com/ifupdown-ng/ifupdown-ng/blob/626a5e8a61ac22e01242ad12b63e30036c2e5298/executor-scripts/linux/dhcp#L16) in ifupdown-ng to start dhcpcd --denyinterfaces '*' unless it is already running. And when the last ifdown happens it kills the manager process.

Another idea is to let dhcpcd spawn the manager process if its not running already when an interface is specified.

[rsmarples]

I have also considered using dhcpcd as the only network manager for alpine linux, but we also need something that can manage bridges and vlans - and we need backwards compatibility

I have entertained the idea of this too, but ruled it out as out of scope.
The dhcpcd program does what it currently does and no more.

If anything, a separate tool would be created to manage links.
This would be akin to the dhcpcd-ui project which has a Gtk+ and Qt front end to dhcpcd and wpa_supplicant.
In the same way you could select an AP via SSID, you could configure OpenVPN or WireGuard.

Another idea is to let dhcpcd spawn the manager process if its not running already when an interface is specified.

This is what will currently happen in dhcpcd-11.
So everything should "just work" still. The only exception I can think of is parallel network starts and then they race.

What won't currently work - but we could make it so - is doing dhcpcd eth0 when dhcpcd is already started and expecting it to block until eth0 has a working lease.

[perkelix]

I don't like this idea. Using dhcpcd as a drop-in replacement for dhclient very much requires being able to start dhcpcd on a per-interface basis. Expecting it to always run it as a daemon that manages any and all interfaces is not desirable.

[perkelix]

@rsmarples It's not just about configuring DHCP. It's about having a flat file to configure all interfaces (including bridge and vlan). ifupdown provides that. dhcpcd doesn't. Basically, Debian derivatives ship ifupdown integration for almost every networking tool.

For instance:

allow-auto br0
allow-hotplug /en* /wl*
iface br0 inet static
	address 172.16.1.1
	bridge_ports regex (enp6s|enp3s|enp2s|wl).*
	post-up /etc/boot.d/iptables_IPv4-MASQ_IPv6-Bridge
iface br0 inet6 auto
iface enp4s0 inet dhcp
iface wlxXXXXXXXXX inet manual
	hostapd /etc/hostapd/hostapd-1-zd1211rw-2G.conf
iface wlxYYYYYYYYY inet manual
	hostapd /etc/hostapd/hostapd-2-rtl8xxxu-2G.conf

Please go ahead and tell me how a demonized dhcpcd would replace all that.

[rsmarples]

Sorry the the late reply.
Firstly, that is not a flat file - it references external files.
Secondly, it can continue working just file if something starts dhcpcd denying all interfaces before that runs.
I don't recall /etc/networking/interfaces controlling boot daemons, so this still fits inside your model.

[perkelix]

The only external files it references are hostap configs for radio frequencies and the iptable rules. The interfaces themselves very much are configured in that flat file, with the sole exception of the IPv6-PD that is configured in dhcpcd.conf

[rsmarples]

OK, I'm not going to argue the point - obviously our views differ.
I personally don't see any difference between an IPv4 address or a radio frequency. Both are equally important when configuring a wireless interface.

[perkelix]

I just noticed another problem with this proposal. Roy's current idea would be to have a default config that denes all interfaces and then issue e.g. "dhcpcd -k enp0s3" to the daemonized dhcpcd to raise that interface. How would we handle prefix delegation in a dhcpcd.conf whose default is to deny all interfaces? Would there be a command line option to specify the PD interfaces?

[perkelix]

I have also considered using dhcpcd as the only network manager for alpine linux, but we also need something that can manage bridges and vlans - and we need backwards compatibility

I have entertained the idea of this too, but ruled it out as out of scope. The dhcpcd program does what it currently does and no more.

Which is precisely what's problematic with this idea of forcing dhcpcd into a daemon. It amounts to imposing it as a one-stop interface configuring tool even though it lacks obvious features such as this.

Basically, doing this would amount to killing dhcpcd's userbase. The userbase is not laptops running dhcpcd-gtk. It is hosts configured via ifupdown.

[holmanb]

@rsmarples I'm continuing the conversation from #276 here, since some of my question could use a broader audience.

dhcpcd-11 will require starting as a service in the same way as apache, postfix or dnsmasq

We shouldn't leave a daemon started in the initramfs running when the init process starts. It sounds like you're amenable to keeping --oneshot, however after #271 is implemented this oneshot will start the daemon in manager mode so the daemon will remain running.

Do I understand correctly that calling dhcpcd --exit after the --oneshot call will be required under dhcpcd-11 to clean up the daemon?

Will --manager be deprecated for removal in a later release (dhcpcd-12)? I'm trying to think about what it would look like today to write calls to dhcpcd that will behave correctly both now and after the transition to dhcpcd-11. For dhcp address on a single interface in the initramfs, I assume we will want something like:

# run client, exit after the interface is configured
# --rebind shouldn't be required if we know that no other dhcpcd daemon has started, right?
dhcpcd --oneshot --manager --rebind <interface>

# clean up the daemon
dhcpcd --exit

Correct?

@rsmarples Do my assumptions above make sense? Am I missing anything? Cloud-init runs early in boot (started by the init system) and will have similar needs once its removal of isc-dhclient dependency is complete.

[rsmarples]

We shouldn't leave a daemon started in the initramfs running when the init process starts. It sounds like you're amenable to keeping --oneshot, however after #271 is implemented this oneshot will start the daemon in manager mode so the daemon will remain running.

Do I understand correctly that calling dhcpcd --exit after the --oneshot call will be required under dhcpcd-11 to clean up the daemon?

No, --oneshot will exit on success as before. I don't see why this would change.
What might be tricky is doing this on >1 interface, but I don't see a use case for that. Do you?

Will --manager be deprecated for removal in a later release (dhcpcd-12)?

Good question! Probably so, yes. I expect to keep it for dhcpcd-11.0 at least.

[holmanb]

Do I understand correctly that calling dhcpcd --exit after the --oneshot call will be required under dhcpcd-11 to clean up the daemon?

No, --oneshot will exit on success as before. I don't see why this would change.
What might be tricky is doing this on >1 interface, but I don't see a use case for that. Do you?

So long as no daemon is left running after the command returns and one interface is satisfied, I think my use cases are satisfied.

I can think of a real-world use case for blocking until all interfaces are configured, but it is contrived and therefore better off configured by an admin via init system configurations rather than in the dhcpcd codebase - it isn't a general enough use-case to worry about in dhcpcd.

[rsmarples]

Prefix delegation works just fine.All the deny interfaces option does is stop dhcpcd from automatically starting on those listed interfaces. ---- On Sun, 10 Mar 2024 18:06:45 +0000 ***@***.*** wrote ---- I just noticed another problem with this proposal. Roy's current idea would be to have a default config that denes all interfaces and then issue e.g. "dhcpcd -k enp0s3" to the daemonized dhcpcd to raise that interface. How would we handle prefix delegation in a dhcpcd.conf whose default is to deny all interfaces? Would there be a command line option to specify the PD interfaces? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[jvfranklin]

One thing I need for my project is the ability to independently send Release messages for IPv4 and IPv6 on more than one interface. Right now, the only way I can accomplish that is to run separate processes for each. Can this kind of thing be incorporated into the roadmap for version 11?

[rsmarples]

This is being fixed in #311 I think

[rsmarples]

@jvfranklin any chance you could test the change in that ticket to ensure it works for you please?

[jvfranklin]

Yes, I'm working on that right now, actually. Our project is an embedded linux system, and it's still on 9.4.1, so it's going to take some minor acrobatics to convert over. Dhcpcd is tightly integrated with our network daemon, and it's all pretty new to us. We're coming to dhcpcd as dhclient refugees after that went end-of-life. :-) Looking forward to working with you.