Bug #14604
open
Bugs in dhclient implementation according to RFC 2131
0%
Description
I had issues with one of the ISPs on pfSense and after talking to their tech support and observing what is happening I believe there are bugs in dhclient used by pfSense.
It is likely an upstream issue, but I don't use FreeBSD, so I report it here.
This is what triggers https://redmine.pfsense.org/issues/14237 (which I believe is a buggy gateway groups implementation in pfSense and is a distinct issue, this one is just one way to trigger it, but maybe not the only one).
Dump of communication between pfSense and DHCP server of ISP is also attached.
The issue happened on 2.6.x and still happens on 2.7.0 that I'm currently running.
Below is basically an English translation of the response from IPS support representative.
The first thing that is believed to be handling DHCPDISCOVER. According to RFC 2131:
The client begins in INIT state and forms a DHCPDISCOVER message.
The client SHOULD wait a random time between one and ten seconds to
desynchronize the use of DHCP at startup.
So client must wait for DHCPOFFER up to 10 seconds. During this time client can receive answers from multiple DHCP servers and pick settings it prefers.
The other issue is that according to RFC 2131 Unicast request Request Renew must be done between T1 and T2. Time approximately equal tothe lease time
(with slight random offset) - T1 timer. pfSense's dhclient only uses T2 (0.85*lease time), this is not quite correct, request according to T2 timer is usually
done in case first request to extend lease failed (depends on implementation and DHCP client settings). According to RFC after T2 time client must switch to
REBINDING and make boardcast request, which is what happened. If cient doesn't send request/doesn't receive response within lease time then settings must be
cleared and procedure of obtaining IP address start over.
Current lease time is 10 minutes (600 seconds).
Separately sometimes dhclient doesn't send DHCPREQUEST within lease time, for instance record #34 and 37, between then there was more than 600 seconds and
procedure to get IP address started over, which is when Internet access was temporarily lost.
Files
Updated by Flole Systems 9 months ago
The ISPs understanding of the RFC is not correct. A client does not need to wait up to 10 second for a response.
Updated by Nazar Mokrynskyi 9 months ago
Flole Systems wrote in #note-1:
The ISPs understanding of the RFC is not correct. A client does not need to wait up to 10 second for a response.
Well, I can see how it can stop early if it gets a response from at least one DHCP server, but it doesn't randomize the time and always gives up exactly after 1 second even without response despite that RFC saying it can take up to 10 seconds for DHCP server to respond.
Linux (tested myself a few times) and Windows clients as well as numerous possible consumer wireless routers don't have such issue (most of them are Linux-based too) with this ISP.
I'm apparently the first and only client of the ISP with DHCP issues and likely the only one (or one of very few) running pfSense/FreeBSD, hence this bug report.
Updated by Nazar Mokrynskyi 9 months ago
Reported upstream in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272827, turns out dhclient needs some updating upstream.
Maybe pfSense developers would be able to do something about it that'll benefit both?
Updated by Christian McDonald 9 months ago
I will look at this, as I’m currently doing a lot of DHCP work at the moment.
(We are also looking at moving to dhcpcd too)
Updated by Nazar Mokrynskyi 8 months ago
Just to manage my expectations, how high is this on your priority list?
I'm thinking whether I should cancel my ISP service since it is almost unusable with current dhclient implementation.
I understand if you have more important things to work on.
If my understanding is correct, upstream dhclient simply needs to be pulled into FreeBSD, which doesn't seem like a massive undertaking on the surface.