pfSense

Looks like lenient-option-parsing might help this, could make that a global option maybe.

https://kea.readthedocs.io/en/kea-2.6.1/arm/dhcp4-srv.html#lenient-option-parsing

Starting with Kea version 2.5.8, this parsing is extended to silently ignore FQDN (81) options with some invalid domain names.

Christian, the PCAP was provided to show the complete exchange, regardless of the DHCP server.

Look at the FQDN option in the DHCP request: the manufacturer's intent is to name the device "generator" but the option is malformed as indicated in the WireShark dump:
Option: (81) Client Fully Qualified Domain Name
Length: 9
Flags: 0x67, Encoding, Server overrides, Server
0110 .... = Reserved flags: 0x6
.... 0... = Server DDNS: Some server updates
.... .1.. = Encoding: Binary encoding
.... ..1. = Server overrides: Override
.... ...1 = Server: Server
A-RR result: 101
PTR-RR result: 110
[Malformed Packet: DHCP/BOOTP]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Malformed Packet (Exception occurred)]
[Severity level: Error]
[Group: Malformed]

The request comes from the device, not KEA.

Serge Caron wrote in #note-3:

Christian, the PCAP was provided to show the complete exchange, regardless of the DHCP server.

Ah okay, than it might be useful to enable lenient-option-parsing

You can test by executing the following one-liner while Kea is running:

echo '{"command":"config-get"}' | nc -U /var/run/kea4-ctrl-socket | jq 'del(.arguments.hash) | del(.result) | .arguments.Dhcp4 += {"compatibility": {"lenient-option-parsing": true}} | .command = "config-set"' | nc -U /var/run/kea4-ctrl-socket

This will modify the running config without restarting Kea. Try obtaining a lease again. Restarting Kea will revert this change.

You can also run this one-liner to enable DEBUG logging:

echo '{"command":"config-get"}' | nc -U /var/run/kea4-ctrl-socket | jq 'del(.arguments.hash) | del(.result) | .arguments.Dhcp4.loggers[0].debuglevel = 55 | .arguments.Dhcp4.loggers[0].severity = "DEBUG" | .command = "config-set"' | nc -U /var/run/kea4-ctrl-socket

Hello Christian,

I have a second installation with the same Cummins generator. I reassigned the VLAN so that the lease is treated by a pfSense 2.7.2 installation.

I can verify that KEA DHCP is running using ps -awx -l from the SSH console (option 8):
0 43942 1 1 20 0 56680 25048 select S - 0:02.64 /usr/local/sbin/kea-dhcp4 -c /usr/local/etc/kea/kea-dhcp4.

Your one-liner has no effect.

In the console environment, I get "jq: command not found":
[2.7.2-RELEASE][admin@vpngateway.pcevolution.com]/root: echo '{"command":"config-get"}' | nc -U /var/run/kea4-ctrl-socket | jq 'del(.arguments.hash) | del(.result) | .arguments.Dhcp4 += {"compatibility": {"lenient-option-parsing": true}} | .command = "config-set"' | nc -U /var/run/kea4-ctrl-socket

[2.7.2-RELEASE][admin@vpngateway.pcevolution.com]/root: echo '{"command":"config-get"}' | nc -U /var/run/kea4-ctrl-socket | jq 'del(.arguments.hash) | del(.result) | .arguments.Dhcp4 += {"compatibility": {"lenient-option-parsing": true}} | .command = "config-set"' | nc -U /var/run/kea4-ctrl-socket
jq: Command not found.

In the "PHP shell + pfSense tools" environment (option 12), I get no reaction whatsoever.

Using the GUI "Diagnostics / Command Prompt", I get no result if the one-liner is executed as a command.

Finally, when executed as PHP, I get the error "Parse error: syntax error, unexpected token "var" in /tmp/user_code/co6bcG on line 7".

Hopefully you have a better suggestion ... or I am not subtle enough to understand your one liner ;-)

doh, you're absolutely correct. textproc/jq is not pre-installed on 2.7.2

pkg install -y jq and try again :)

The lenient-option-parsing option won't help on CE 2.7.2 since it's on Kea 2.4.0, you'd need to be on the Plus 24.11 beta (or later) which has Kea 2.6.1 since the behavior for this option was only changed in Kea 2.5.8.

Even Plus 24.03 wouldn't work since it only has Kea 2.4.1.

ah good catch

Looking at the 2.8.0 roadmap, I still have a chance to see a resolution in the next six months ;-)

Kind regards,

One last note on this DHCP server migration.

The packet capture in the 2.7.2 distribution correctly shows options 60 and 255 following the FQDN field (option 81). Using the medium view level, we have:

14:22:39.691577 IP (tos 0x0, ttl 64, id 5, offset 0, flags [none], proto UDP (17), length 357)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:1c:e8:00:c3:c4, length 329, xid 0x22334456, secs 64, Flags [Broadcast]
Client-Ethernet-Address 00:1c:e8:00:c3:c4
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Request
Requested-IP (50), length 4: 192.168.166.139
Subnet-Mask (1), length 4: 255.255.255.0
Default-Gateway (3), length 4: 192.168.166.1
Domain-Name-Server (6), length 4: 192.168.166.1
Lease-Time (51), length 4: 86400
Parameter-Request (55), length 4:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
Server-ID (54), length 4: 192.168.166.1
FQDN (81), length 9: [ERROR: MBZ nibble 0x6 != 0] [SOE] 101/110 "erator"
Vendor-Class (60), length 30: "Cummins Home-Standby Products^J"

WireShark and the likes discard the rest of the packet following the option in error and we don't get to see the rest of the packet data.

In the case of the Cummins firmware, their FQDN field (option 81) is formatted exactly like the host name (option 12).

I do not know the prevalence of such confusions, but I have a factory full of devices manufactured over the last 20 years and I will be looking for lenient-option-parsing before I discard the obsolete ISC server.