DHCPCD started on its own works just fine:

dhcpcd[13391]: version 6.0.5 starting
dhcpcd[13391]: eth0: soliciting an IPv6 router
dhcpcd[13391]: eth0: soliciting a DHCP lease
dhcpcd[13391]: wlan0: soliciting an IPv6 router
dhcpcd[13391]: wlan0: soliciting a DHCP lease
dhcpcd[13391]: eth0: Router Advertisement from fe80::20b:beff:fefd:b37f
dhcpcd[13391]: eth0: soliciting a DHCPv6 lease
dhcpcd[13391]: wlan0: offered bla.71.49 from 172.24.6.65
dhcpcd[13391]: eth0: Router Advertisement from fe80::21e:7aff:fef4:fd7f
dhcpcd[13391]: eth0: ADV bla:d4c9::14c9/64 from fe80::202:b3ff:fe98:c030
dhcpcd[13391]: eth0: REPLY6 received from fe80::202:b3ff:fe98:c030
dhcpcd[13391]: eth0: adding address bla:d4c9::14c9/64
dhcpcd[13391]: eth0: renew in 3600 seconds, rebind in 7200 seconds
dhcpcd[13391]: forked to background, child pid 13471

right, it's not saying that dhcpcd doesn't support IPv6, it's saying that NetworkManager's dhcpcd backend doesn't support IPv6. ie, NM doesn't know what options to use, or in what form the information will come back

(In reply to comment #2)
> right, it's not saying that dhcpcd doesn't support IPv6, it's saying that
> NetworkManager's dhcpcd backend doesn't support IPv6. ie, NM doesn't know what
> options to use, or in what form the information will come back

Correct. Also I don't know whether dhcpcd is usable as a standalone DHCPv6 client at all. Normally it's trying to act as a full-fledged network configuration daemon, which won't work well with NetworkManager, but maybe it can be tweaked to work as a DHCPv6 client.

I don't actually see any real reason to use NetworkManager with dhcpcd as most notable features of dhcpcd are those that are not useful when using a network daemon. Reports like this one suggest that it would be best to remove the dhcpcd backend from NetworkManager as it only causes trouble.

we take patches

(In reply to comment #4)
> we take patches

Where do you see them?

Also note that dhcpdc 5.99+ made IPv6 *automatic*, so just upgrading the version makes it do IPv6 stuff where before it did not.  Extremely unhelpful.  There are the -4 and -6 options, but it appears that they don't actually do anything, since they just affect how the 'help' printouts appear.

So you cannot force dhcpcd to disable IPv6 without writing a config file.  I guess NM could do this for now, but making -4 and -6 do what they should do would be a better option.

IPV6 by default is a problem because some WWAN modules do not support IPv6, but when they try to start it in response to an RS, they crash (early Qualcomm Gobi devices, for example).  So just upgrading dhcpcd makes peoples WWAN magically stop working.

But in the end, yes, NM should eventually grow IPv6 support for dhcpcd.  However, we do *only* want dhcpcd doing DHCP stuff, we do not want it doing IPv6 router solicitations, since NetworkManager handles that becuase it knows better than dhcpcd when IPv6 is supposed to be used...

Ah, -4 and -6 do work, I just wasn't looking in the right place.

Hi,
I am resurrecting this bug because the issue is still there. What is the official recommendation? Stop using the dhcpcd backend and switch to dhclient?

(In reply to Antonio from comment #8)
> Hi,
> I am resurrecting this bug because the issue is still there. What is the
> official recommendation? Stop using the dhcpcd backend and switch to
> dhclient?

Use whatever works for you. If something doesn't work, use something else or send a patch to fix it.

dhcpcd didn't get much love in recent years, so I would expect that both dhclient and the internal client works better. We care very much that dhclient and the internal plugin work well, and I am not aware of issues there. That decreases the incentive to improve dhcpcd plugin (patches welcome though!!).

In the future, the internal plugin should be the preferred way. However dhclient allows for a lot of customizing, so it will be hard for the internal plugin to replace dhclient for every use case. Especially, it will be impossible to replace dhclient with the internal library without affecting existing setups. I think dhcpcd should be eventually dropped, unless somebody cares enough about it.

The internal plugin has another problem over dhclient: dhclient (at least with downstream patches) drops capabilities. With dhclient the network facing code is better isolated. So, dhclient may (or may not?) be more secure.

(In reply to Thomas Haller from comment #9)
> (In reply to Antonio from comment #8)
> In the future, the internal plugin should be the preferred way. However
> dhclient allows for a lot of customizing, so it will be hard for the
> internal plugin to replace dhclient for every use case. Especially, it will
> be impossible to replace dhclient with the internal library without
> affecting existing setups. 

Any special reason to reimplement the dhcp logic inside NM when dhclient is already there and (apparently) somewhat more powerful?

Actually extracting the interesting code and making a library out of it might even be better :)

But I understand it might be "simpler" to have an internal plugin.


Personally I don't have much interest in dhcpcd per se, therefore I am not motivated enough to fix its support.

Thanks a lot for the explanation.

(In reply to Antonio from comment #10)
> (In reply to Thomas Haller from comment #9)
> > (In reply to Antonio from comment #8)
> > In the future, the internal plugin should be the preferred way. However
> > dhclient allows for a lot of customizing, so it will be hard for the
> > internal plugin to replace dhclient for every use case. Especially, it will
> > be impossible to replace dhclient with the internal library without
> > affecting existing setups. 
> 
> Any special reason to reimplement the dhcp logic inside NM when dhclient is
> already there and (apparently) somewhat more powerful?

It is an additional dependency which increases the base-image. It consumes 8 MB of RAM for me now (actually, I thought it would consume more. I seem to remember it used 20 MB on my machine, did it improve?). NM itself already consumes more memory then we would like.

Bug like https://bugzilla.redhat.com/show_bug.cgi?id=1093803 goes unfixed for a long time. dhclient uses a raw socket, which decreases performance as the NIC is in promisc mode (at least a while a ago, didn't check now).
This would be fixable, but it it seems it's a mature codebase that is not moving fast.

> Actually extracting the interesting code and making a library out of it
> might even be better :)

Well, that is what happens. Except that we don't take the ISC code but systemd code. The internal plugin is mostly copy&paste of the systemd sources [1][2]. 
The code as 2 users: systemd-network, NM. And ConnMan developers also contributed to the code (but I don't think that ConnMan uses it, at least not yet).

The code isn't a proper library, because nobody is investing the necessary work. Which at this point mostly means to communicate with systemd what to do. Also, systemd doesn't seem very interested in moving this forward either (which is very understandable because it mostly works for everybody, but it's unfortunate overall).


[1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/dhcp/nm-dhcp-systemd.c?id=85e3f956adea7d065c7773891ea48f0f968a4d14
[2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/systemd?id=85e3f956adea7d065c7773891ea48f0f968a4d14

bugzilla.gnome.org is being shut down in favor of a GitLab instance. 
We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/

Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).