Project

General

Profile

Actions

Bug #13573

closed

DHCP Server generates an invalid configuration for static mappings when defining network booting and UEFI HTTPBoot URL

Added by Jason Montleon about 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
DHCP (IPv4)
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
23.05
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

If I go down to Network Booting, check enable, and add a UEFI HTTPBoot URL pfSense adds an option for every static mapping

host s_lan_0 { hardware ethernet ... fixed-address ... option host-name ... option custom-s_lan_0-0 "HTTPClient"; }

On service restart logs show Oct 18 09:46:13 dhcpd 2326 /etc/dhcpd.conf line 43: unknown option dhcp.custom-s_lan_0-0 for each static lease and then the server crashes.

I nuked all these on the CLI and restarted the server with /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/dhcpd.pid and everything worked as expected until the next service restart when the config was overwritten.

If I disable network booting and restart these are removed and the server starts.


Related issues

Has duplicate Bug #13554: Configuration file error caused by setting UEFI HTTPBoot URL in DHCP ServiceDuplicate

Actions
Actions #1

Updated by Jason Montleon about 2 years ago

May be the same or related to https://redmine.pfsense.org/issues/13554, but this was referencing vlan configuration instead of static mappings, so I am not certain.

Actions #2

Updated by Kris Phillips almost 2 years ago

I'm unable to reproduce this in pfSense Plus 23.01. Can you please test this on the latest development version to verify it's fixed?

I did the following:

1. Added static mapping
2. Enabled Network Booting, set a "Next Server IP", and a HTTPBoot path.
3. Saved, applied, and restarted dhcpd

The service seems to have started each time without issue.

Actions #3

Updated by Jim Pingle almost 2 years ago

  • Status changed from New to Feedback
Actions #4

Updated by Jason Montleon almost 2 years ago

This still happens for me on 23.01-RELEASE.


Feb 16 21:48:55    dhcpd    35012    exiting.
Feb 16 21:48:55    dhcpd    35012    process and the information we find helpful for debugging.
Feb 16 21:48:55    dhcpd    35012    before submitting a bug. These pages explain the proper
Feb 16 21:48:55    dhcpd    35012    bugs on either our web page at www.isc.org or in the README file
Feb 16 21:48:55    dhcpd    35012    than a configuration issue please read the section on submitting
Feb 16 21:48:55    dhcpd    35012    If you think you have received this message due to a bug rather
Feb 16 21:48:55    dhcpd    35012    Configuration file errors encountered -- exiting
Feb 16 21:48:55    dhcpd    35012    ^
Feb 16 21:48:55    dhcpd    35012    option custom-s_lan_34-0 "HTTPClient" 
Feb 16 21:48:55    dhcpd    35012    /etc/dhcpd.conf line 319: unknown option dhcp.custom-s_lan_34-0
...

If I uncheck 'Enable network booting' and save the server starts up as expected.

Actions #5

Updated by Jason Montleon almost 2 years ago

Actions #6

Updated by Jim Pingle almost 2 years ago

  • Project changed from pfSense Plus to pfSense
  • Category changed from DHCP Server (IPv4) to DHCP (IPv4)
  • Status changed from Feedback to New
  • Target version set to 2.7.0
  • Affected Plus Version deleted (22.05)
  • Plus Target Version set to 23.05
Actions #7

Updated by Jim Pingle over 1 year ago

  • Has duplicate Bug #13554: Configuration file error caused by setting UEFI HTTPBoot URL in DHCP Service added
Actions #8

Updated by Jim Pingle over 1 year ago

  • Status changed from New to In Progress
  • Assignee set to Jim Pingle

I was able to replicate this from a stock config with just three changes:

  • Network booting checked
  • HTTPBoot URL defined
  • One static mapping entry on the interface

Without a static mapping, there was no error.

It appears to be trying to reuse the global numbered options for the static mapping but forming the name incorrectly or failing to re-define it. Not exactly clear yet.

Here is the entire generated configuration:


option domain-name "home.arpa";
option ldap-server code 95 = text;
option domain-search-list code 119 = text;
option arch code 93 = unsigned integer 16; # RFC4578
option custom-lan-0 code 60 = text;

default-lease-time 7200;
max-lease-time 86400;
log-facility local7;
one-lease-per-client true;
deny duplicates;
update-conflict-detection false;
authoritative;
class "s_lan" {
    match pick-first-value (option dhcp-client-identifier, hardware);
}
subnet 192.168.1.0 netmask 255.255.255.0 {
    pool {

        range 192.168.1.100 192.168.1.199;
    }

    option routers 192.168.1.1;
    option domain-name-servers 192.168.1.1;
    ping-check true;

    option custom-lan-0 "HTTPClient";
    if substring (option vendor-class-identifier, 0, 10) = "HTTPClient" {
        filename "http://10.34.0.55:1234/tftp/ipxe.efi";
    }

}
host s_lan_0 {
    hardware ethernet 90:ec:77:47:5e:58;
    fixed-address 192.168.1.9;
    option host-name "blah";

    option custom-s_lan_0-0 "HTTPClient";
}
subclass "s_lan" 1:90:ec:77:47:5e:58;

Note that in the definition at the top and on the interface it's custom-lan-0 but in the static mapping the name is option custom-s_lan_0-0.

Looking at the code it appears to be using the wrong variables for that section, it's checking the pool config when it should be checking the static mapping config.

Actions #9

Updated by Jim Pingle over 1 year ago

  • Subject changed from Adding a UEFI HTTPBoot URL and enabling network booting with static mappings causes dhcpd to crash to DHCP Server generates an invalid configuration for static mappings when defining network booting and UEFI HTTPBoot URL

So not only was this breaking HTTPBoot in general with static mappings, but it also was preventing that option from being used on a per-mapping basis. Fix coming momentarily that addresses both.

Actions #10

Updated by Jim Pingle over 1 year ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 100
Actions #11

Updated by Jason Montleon over 1 year ago

I added a custom system patch with this and it works for me. Thank you!

Actions #12

Updated by Lev Prokofev over 1 year ago

Able to reproduce on

23.01-RELEASE (amd64)
built on Fri Feb 10 20:06:33 UTC 2023
FreeBSD 14.0-CURRENT

After the patch, I can start the DHCP server normally.

Actions #13

Updated by Jim Pingle over 1 year ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF