dhcpd losing hostnames

Chris Buechler cbuechler at gmail.com
Fri Jul 15 18:28:21 UTC 2016


On Tue, Jul 12, 2016 at 2:57 PM, Shawn Routhier <sar at isc.org> wrote:
>
>> On Jul 11, 2016, at 8:58 PM, Chris Buechler <cmb at pfsense.org> wrote:
>>
>> On Mon, Jul 11, 2016 at 9:52 PM, Michael Vincent <vyncebox at gmail.com> wrote:
>>> A few pfSense 2.3.1 (based on FreeBSB 10.3) users have noticed an
>>> issue with the dhcp server (ISC DHCP Server 4.3.3-P1) losing client
>>> hostnames regularly. Packet captures have proven that while hostnames
>>> are always provided by clients and generally recorded in dhcpd.leases,
>>> the hostnames often disappear from dhcpd.leases after some period of
>>> time. We haven't been able to conclusively prove that dhcpd itself is
>>> to blame, but investigations of packet captures and logs are pointing
>>> in that direction.
>>>
>>> Background is available in this thread:
>>> https://forum.pfsense.org/index.php?topic=110011.0 and a bug ticket
>>> has been opened here: https://redmine.pfsense.org/issues/6589
>>>
>>
>> To elaborate on this a bit, the reason for the root problem is
>> dhcpd.leases file doesn't always have client-hostname specified,
>> though the client always sends it. We have a daemon that processes
>> dhcpd.leases and registers hostnames in dnsmasq and/or Unbound from
>> that (since they can't do proper DDNS), which is kind of a hack, but
>> the only way to accommodate those in that circumstance.
>
> I hope that should be read that dnsmasq and Unbound have issues with
> proper DDNS?  The current servers should be doing DDNS correctly
> and if they aren’t we’d like to know about issues.
>

Neither of them support RFC 2136, as they're not considered
authoritative DNS servers. In dnsmasq's case you have to populate the
hosts file, in Unbound's, hard code in its conf file.


>> So it appears there's a regression in 4.3.x with recording
>> client-hostname to the leases file.
>
> Some questions to help with isolating the problem
> 1) Do you know if anybody has created a bug ticket for this in the past?
>

Not that I'm aware of.


> 2) You mention 4.3.3 and 4.3.4, do you know if the problem started showing
> up earlier than that for example in 4.3.0?
>

4.3.2 was the first 4.3.x version we shipped as part of pfsense, not
sure on any 4.3.x prior to that.


> 3) From some of the descriptions on the first of the two links above it sounds
> like dhcp-cache-threshold may be causing issues.  This was added in 4.3.0
> and tries to avoid updating a lease if that isn’t necessary.  Instead it re-uses
> the lease information (expiration time and etc) from the current lease and
> thus avoids doing an fsync.
> You can try to disable it by setting it to 0, add the following line in your config:
> dhcp-cache-threshold 0;
> and see if that affects the problem.
>

Judging by the reports of Michael in this thread, and another of our
users on our forum, setting 'dhcp-cache-threshold 0' works around the
issue. I made that change so we have a workaround available for users.
https://redmine.pfsense.org/issues/6589
https://forum.pfsense.org/index.php?topic=110011.15

> 4) Have people seen this that aren’t using pfsense?
>

I doubt many, if any other people rely on client-hostname's presence
in the leases file to the extent they'd notice its absence.


> 5) From the description in the pfsense chain it sounds like the client hostname
> is always being included in the DHCP messages - is that correct?
>

Yes, I've also confirmed that to be the case. I've seen systems where
a pcap of the DHCP requests show the hostname, and then the leases
file ends up not having it.

Thanks for the help, we at least have a workaround available now. For
our users' use cases, disabling the dhcp-cache-threshold is an
acceptable workaround in the mean time until the root cause is fixed.


More information about the dhcp-users mailing list