Failover peer IP breaking DHCP
-
Sent you a copy of /var/dhcpd/etc/dhcpd.conf when it's broken
-
Line 32 in that file is much higher than what you quoted, it's one of these:
ignore dynamic bootp clients; ignore unknown-clients;Are you trying to deny unknown clients? Or what other options do you have set on that interface?
In mine, I have:
deny dynamic bootp clients;And it's working here, but I suspect there is some other difference in the config at play
-
Yes, I have set the option to deny unknown clients and ignore denied clients.
I just picked what the edit file - go to line# highlighted for me. Seemed to be line 32.
Only other option I have set is…
Time format change Change DHCP display lease time from UTC to local time
DNS and gateway are updated to reflect CARP
-
It looks like failover doesn't agree with "Ignore denied clients" enabled. It chokes on the config when that's enabled along with failover. I'll start a ticket, looks like it might need some input validation to prevent that from being selected together.
-
Opened a ticket for it here: https://redmine.pfsense.org/issues/5898
-
Opened a ticket for it here: https://redmine.pfsense.org/issues/5898
Awesome.. so you were able to replicate this?
-
Yes, the moment I checked "Ignore …" it failed every time unless I unset the failover address. It would appear the two are not compatible, so I'm adding input validation to prevent them from being combined.
-
OK I pushed a fix for it, visible on https://redmine.pfsense.org/issues/5898
In the future if you check the box when a failover peer is defined, it will warn you that they cannot be used together, forcing either the "ignore" box to be unchecked, or the failover peer IP to be removed manually.
-
Awesome..
Please put my name in the fix.. lol .. ;)
Also, should the incompatibility be rectified sometime in future?
-
The compatibility is up to ISC – it's their daemon, the daemon is rejecting the setting. So if you need to use them together, advocate upstream to have them fix it.
In the past they've had similar issues that were actually OK and just an over-protective parser rejecting it, but in this case it seems more deliberate, so there may be a reason.
