FS#42886 - [dhcpcd] [dhclient] dhcpcd should be replaced by dhclient in default installations

Attached to Project: Arch Linux
Opened by Fedor Dostoyevskiy (bachtiar) - Sunday, 23 November 2014, 16:55 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 05 March 2018, 23:48 GMT
Task Type General Gripe
Category System
Status Closed
Assigned To Ronald van Haren (pressh)
Christian Hesse (eworm)
Anatol Pomozov (anatolik)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

dhclient is badly designed, it does not support DHCP protocol correctly. It is intended to run once, obtain a IP and exit. This has at least two serious drawbacks:
* If DHCP server is not available when dhcpcd runs, the machine will never get an IP. Consider for example when the power comes back after outage and DHCP client machine boots faster than DHCP server. The client machine will be inaccessible over network.
* It does not respect the fact that DHCP leases eventually expire. The machine will keep a lease even when it has already expired, which could lead to duplicate IPs on the network, bringing several machines down.

Summary: dhcpcd is not for serious use, as it can cause a server to become unreachable. I recomment replacing it with dhclient, which is a fully functional DHCP client.

Additional info:
* package version(s): dhcpcd 6.6.2-1

Steps to reproduce:
* Install dhcpcd
* systemctl enable dhcpcd@eth0.service
* OR: use netctl and specify IP=dhcp in configuration file

As far as I see, this affects systemd unit and netctl.

In theory, both dhclient and dhcpcd could coexist, i.e.:
systemctl disable dhcpcd@eth0.service
systemctl enable dhclient@eth0.service
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Monday, 05 March 2018, 23:48 GMT
Reason for closing:  Won't implement
Additional comments about closing:  OP has more or less retracted his opinion, and over 3 years later no one seems interested in making this change -- possibly for good reason.
Comment by Dave Reisner (falconindy) - Sunday, 23 November 2014, 17:10 GMT
dhclient has its own drawbacks. It doesn't fully adhere to the DHCP RFC and lacks support for a lot of commonplace server extensions. Upstream also lags behind what anyone today considers to be a "modern" userspace. To wit, Arch must heavily patch /usr/bin/dhclient-script to use iproute2 (ip) instead of the obsolete net-tools (ifconfig and route).

Have you considered turning your rant into actionable feedback for dhcpcd upstream? Roy Marples is active on this bug tracker and has been very responsive to bug reports. Far more responsive than ISC ....
Comment by Roy Marples (rsmarples) - Monday, 24 November 2014, 10:49 GMT
I'm the upstream author for dhcpcd (disclaimer, I don't use Arch or systemd)

Firstly, are your initial arguments about dhcpcd instead of dhclient? I'll assume they are :)

dhcpcd fully supports all DHCP related protocols, both v4 and v6.
It is intended to assign an IP address and then fork into the background, or exit with an error *when run for one interface as you are doing*.
If the DHCP server is not available, then dhcpcd will assign a valid IPv4LL address or run a configured fallback address or arping procedure to obtain a valid working IP address.
dhcpcd always respects when leases expire. Unlike other clients, dhcpcd bases the lease length on the OS's monotonic clock, not the RTC time. It also calculates the initial lease time from the lease files mtime, which IS based on your RTC clock - so if that changes before it during the boot process then it will be wrong.
Again, unlike other DHCP clients, dhcpcd checks the attached network for duplicate address (IPv4) or listens to the kernel address flag changes (IPv6) for duplicate addresses. Of course, the Arch wiki recommends disabling that for home networks so dhcpcd boots faster.

So in summary, I would imagine all your problems with dhcpcd would go away if you ran dhcpcd in master mode and not for a specific interface.
ie, systemctl enable dhcpcd.service
Comment by Roy Marples (rsmarples) - Monday, 24 November 2014, 11:07 GMT
I'm going to assume that you have an issue with the 6.6x series with features a new ARP state engine.
One of the changes is that we start IPv4LL a lot earlier and have removed the code which extended the global timeout because of this. So you could be hitting the hard timeout sooner.
As systemd encourages non forking daemons, and the service file should already have the -B flag (I've not looked to see if this is the case on Arch) then this patch may help:

http://roy.marples.name/projects/dhcpcd/ci/62e91328e4bb613e38f9abeb52cb1abe6bfa67cc?sbs=0
Comment by Fedor Dostoyevskiy (bachtiar) - Tuesday, 25 November 2014, 06:50 GMT
I believe this bug report was made in error due to my lack of understanding.

The source of the problem turned out to be in dhcpcd@.service, which calls dhcpcd without "-b" (background immediately) and "-t 0" (no timeout) with respect to Type=forking.

Without "-t 0", dhcpcd exits if there is no reply during boot.

With "-t 0", but without "-b", dhcpcd gets killed by systemd because it doesn't fork in expected time if there is no reply during boot.

In any of those cases, dhcpcd is not running after boot and the machine never gets an IP.

On the other hand, if dhcpcd successfully gets an IP, it keeps running and supposedly it should also renew a lease when neccessary.

I imagine that if someone configures an interface for DHCP, the reasonable and expected behaviour is to keep dhcpcd running in any case. So it might make sense to add "-b -t 0" by default to dhcpcd@.service and to netctl scripts.
Comment by Roy Marples (rsmarples) - Tuesday, 25 November 2014, 09:19 GMT
When -b is given, -t is not evaluated so it's pointless adding it.
Comment by Roy Marples (rsmarples) - Wednesday, 26 November 2014, 17:56 GMT
Solved on the forums.
https://bbs.archlinux.org/viewtopic.php?id=190141

Arch devs may wish to read and evaluate.
Comment by Isenmann Daniel (ise) - Tuesday, 07 July 2015, 07:22 GMT
Just for information: At the moment I have too little time for Arch, I will do my best to find a solution in the next upcoming weeks.
Comment by Otávio Cipriani (oncipriani) - Friday, 11 September 2015, 23:39 GMT
According to Gentoo's NetworkManager Wiki page (https://wiki.gentoo.org/wiki/NetworkManager), "it's a good idea to use dhclient instead of dhcpcd as 1.0.0 version is already doing. While dhcpcd in standalone mode provides some interesting features over dhclient, those will not be used by NetworkManager. Most upstream developers and most users of other distributions do use dhclient and it's therefore much better tested, works correctly with IPv6 and is generally a better DHCP client to be used with NetworkManager".

I do not know if dhcpcd is indeed buggy when used with NetworkManager, but since NetworkManager is required by GNOME, Cinnamon and KDE and depends on dhclient, to me it makes sense to replace dhcpcd with dhclient on the "base" group.
Comment by Roy Marples (rsmarples) - Saturday, 12 September 2015, 00:24 GMT
I use KDE and GNOME.
NetworkManager is an optional application, not a hard requirement. If it was a hard requirement, I would not be able to use either GNOME or KDE on non Linux systems as NetworkManager is Linux only no?

But frankly this is the wrong tree to be barking up - Arch now uses SystemD which comes with it's own DHCP client.

> While dhcpcd in standalone mode provides some interesting features over dhclient, those will not be used by NetworkManager.

This is because dhcpcd now competes with NetworkManager. So there will be bias to remove dhcpcd support (and to be fair, I have bias against NetworkManager).
In summary, a 220k program with zero dependencies other than POSIX and a supported OS (many, not just Linux) competes with a program that requires a basic DHCP client whose size is measured in megabytes.
I don't know how much big Network Manager is.

> Most upstream developers and most users of other distributions do use dhclient and it's therefore much better tested

This, frankly is FUD.
dhcpcd runs on all Android devices which is massive market, probably amounts to more than all other distros put together.

FreeBSD and OpenBSD (and thus derivatives) have their own take on dhclient (hint, it's nothing like ISC dhclient anymore and won't work with NetworkManager).
RedHat and Debian (and ofc derivatives such as Ubuntu) use dhclient as their primary DHCP client.
However, Gentoo, NetBSD, Slackware and Arch (currently) use dhcpcd.

Most other distributions probably don't amount to much compared to the above.

> works correctly with IPv6

So does dhcpcd, prove me wrong please :)
Infact, the stock dhclient fails to implement a RFC requirement for dual stack DHCP - so it's either a DHCPv4 or DHCPv6 client but not both.

> is generally a better DHCP client to be used with NetworkManager

I don't doubt that for one second. After all, the NetworkManager developers don't use anything else.

So, some questions:
Does Arch require a DE?
Does any DE have a hard dependency on NetworkManager?

Lastly, the NetworkManager team are focusing on using the SystemD network stack I think, which will rule out using dhclient as well.
Comment by Roy Marples (rsmarples) - Saturday, 12 September 2015, 07:42 GMT
The Gentoo wiki has been updated to read like so:

It's a good idea to use dhclient from net-misc/dhcp instead of net-misc/dhcpcd as 1.0.0 version is already doing. While dhcpcd in standalone mode provides some interesting features over dhclient, those will not be used by NetworkManager. Most NetworkManager developers do use dhclient and it's therefore much better tested with NetworkManager and is generally a better DHCP client to be used with NetworkManager. NetworkManager does not use the IPv6 support of dhcpcd and instead relies on dhclient for this.
Comment by Fedor Dostoyevskiy (bachtiar) - Saturday, 12 September 2015, 15:00 GMT
As the one who has opened this ticket, I feel obliged to add my 2 cents to this debate.

Since my initial comment, mr. Marples has kindly explained to me that much of my trouble was actually caused by a missing command line switch that keeps dhcpcd in memory, retrying to request a lease if one cannot be obtained at boot, and renewing it once expires. I admit I wasn't thorough enough to research this in more detail before posting, and I apologise for that.

At least for IPv4, the title should actually read "make dhcpcd run in persistent mode in default installations".

Other than that, I really like the fact that dhcpcd is so small and free of dependencies. I think this shows the hard work that the authors have put into it. It is also a good example of Arch philosophy and power of people. I can not judge from other aspects, but at least it solved the problem for me.

Loading...