I need a compatibility workaround from Kea 3.2. What should my expectations be?

ryan87

Does anyone know what the deprecation timeline looks like for ISC DHCP? We have about 110 customers with pfSense firewalls and a fair number of them use alarm panels from this vendor:

The devices set both n=1 and s=1 in DHCP option 81 when making requests. Kea ignores those requests as a violation of RFC 4702. Version 3.2.0 of Kea re-implements the behavior of ISC DHCP and ignores the n bit if "lenient-option-parsing": true.

NOTE: The docs say the workaround was added in 3.1.9, but, as far as I can tell, it's not actually merged until 3.2.0.

Here's the Kea issue, commit that adds the workaround, and the related merge request. Here are the Kea release plans. Looking at the release plans, and assuming pfSense is trying to stick to LTS releases, I'm not sure when the next LTS release is, but I'm guessing 3.4.0 in Q2 2027 would be the best case scenario.

Now that I understand why we've started to have DHCP problems with these panels we can temporarily stay on ISC DHCP for customers that use them, but they're going to turn into a pretty big pain for us if ISC DHCP is removed from pfSense before the included version of Kea is 3.2.0+.

The reason these panels will become a problem is that, as far as I know, they don't have any kind of remote config, there's some kind of system where a contact can get frequent calls (every ~6h) when it's disconnected, and I assume most of them are monitored in some way.

Can anyone tell me what my expectations should be in terms of seeing that change land in pfSense? We've been recommending Netgate devices as APU2s with CE get to EoL, so a dependency of pfSense+ would be tolerable for us if it makes a difference.

Something kind of neat... ChatGPT was able to notice a pattern in the flags being sent for option 81:

# Option 81 - flags to FQDN:

69 6e 69 63 68 65
 |  |  |  \_____/
 |  |  |      "che"
 |  |  +-------- RCODE2 = 'i' = 105
 |  +----------- RCODE1 = 'n' = 110
 +-------------- flags = 'i' = 0x69

# 69 6e 69 63 68 65 = iniche
# vendor class = InterNiche Portable TCP/IP, v4.0 dev

If anyone else thinks they're trying to debug a similar issue, I think pfSense 26.07 includes an option to change the Kea log level. After that, the logs make the issue clear (the bad-packets label on the log is from adding a custom logger):

Aug 21 16:51:33 pfsense kea-dhcp4[78092]: DEBUG [kea-dhcp4.bad-packets.0x29858e079010] DHCP4_PACKET_DROP_0001 [hwtype=1 00:re:da:ct:ed:00], cid=[no info], tid=0x22334498: failed to parse packet from 0.0.0.0 to 255.255.255.255, received over interface ix1, reason: opt_type: 81, opt_len: 6, error: both N and S flag of the DHCPv4 Client FQDN Option are set. According to RFC 4702, if the N bit is 1 the S bit MUST be 0, hwaddr=00:re:da:ct:ed:00

Gertjan

@ryan87

The Option 81 'flags' are bits is a one byte size field :

https://datatracker.ietf.org/doc/html/rfc4702#section-2.1.
That's not a text ASCI string ... ? Right ?!
Just thinking out loud.

If your panels make up their own sauce while using RFC4702, and that breaks with Kea but worked with ISC, then I get it, the panel vendor would be aware of this already.
I presume 'updating' the firmware of a panel is 'not possible'.
( and that's strange, its a security device, right ^^ so not being able to update would make this panel anything but not a security device ... just think even more, and yeah, not very helpful, I get it)

If there was a recent kea update/commit, then they know they had the RFC wrong.

I really do thing ( sorry) that you can use ISC for a while, the time needed for you to get a good kea, like future, 3.2.0.

Afaik, pfSense will only drop ISC if a huge security issue is found, and it can't be correct the bug anymore, and as the author (ISC) pulled the plug years ago.

ryan87

@Gertjan said in I need a compatibility workaround from Kea 3.2. What should my expectations be?:

The Option 81 'flags' are bits is a one byte size field :

https://datatracker.ietf.org/doc/html/rfc4702#section-2.1.
That's not a text ASCI string ... ? Right ?!
Just thinking out loud.

Yeah. I didn't explain it super well. The byte for the flags is only the first letter ( i ):

01101001 = 0x69 = i

It's not important. I just thought it was neat that ChatGPT noticed the pattern between what they're putting into option 81 and the vendor name.

And you got most of the rest about right. The vendor should know they have an issue, they should have an update, etc.. It's (edit) not something we deal with directly, so I don't have any concrete info.

Gertjan

@ryan87

So the real issue is : stuff needs to be update, or at least acknowledge that they use something not RFC compliant.
The fact that kea updated their DHCP server tells me that the real issue isn't your devices only, but also theirs ?!
Anyway, I understand your question : is easier to solve the issue on 'your side' = pfSense.
You found a reason to keep ISC DHCP for a while, as you know a solution is coming up in the near future for kea.

Extra :
As option 81 is already hardcoded into kea, as it's an RFC, you can't create your own option 81 handler. That is, I'm not sure if you can override it (haven't looked it up).

Btw : I don't agree with ChatGP here.

hex 51 is dec 81 = the option code.
hex 06 is dec 6 = the string (the URL) length
hex 69 or 0110 = '6' (why are these two middle bits set ? )
and then 1001 (= dec or hex 9) = No DDNS server update (whatever that means) and he final '1' means 'server (whatever that means)
Then comes the FQDN.
6e 69 63 68 65 = "niche" and not as what is mention above "che". For me, ChatGP doesn't know how the interpret DHCP opcode code 81, which is pretty basic, the code ID 81 (a byte) , the length (a byte) , the Flags (a byte) and then the asci text string which must be a FQDN.
Is "niche' or 'che' a FQDN ?? Hummmm...

Btw : this is my interpretation of course. So get me right, I love it be wrong of course ^^

edit :

Packet capture DHCP traffic on my pfSense : LAN, Full details, protocol UDP and ports "68 69" and start.
Now, on my PC :

ipconfig /renew

and bingo - this is the pfSense DHCP server answer :

13:32:07.687283 90:ec:77:29:39:2c > a4:bb:6d:ba:16:a1, ethertype IPv4 (0x0800), length 359: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 345)
    192.168.1.1.67 > 192.168.1.6.68: [udp sum ok] BOOTP/DHCP, Reply, length 317, xid 0xd8992e8f, Flags [none] (0x0000)
	  Client-IP 192.168.1.6
	  Your-IP 192.168.1.6
	  Client-Ethernet-Address a4:bb:6d:ba:16:a1
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: ACK
	    Subnet-Mask (1), length 4: 255.255.255.0
	    Default-Gateway (3), length 4: 192.168.1.1
	    Domain-Name-Server (6), length 4: 192.168.1.1
	    Domain-Name (15), length 20: "brit-hotel-fumel.net"
	    Vendor-Option (43), length 6: 1.4.192.168.1.9
	    Lease-Time (51), length 4: 16760
	    Server-ID (54), length 4: 192.168.1.1
	    FQDN (81), length 11: [N] "gauche2."

So .... hum again.
The length is here "11" - if that's true, it includes the option code itself, length byte itself, it Flag byte, and the FQDN "gauche2." and yes, there is a dot at the end so this looks way more as a valid FQDN.
"gauche2" is the name of my PC.

Btw : My PCn the DHCO client, also uses option dec '81' :

....
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Request
	    Client-ID (61), length 7: ether a4:bb:6d:ba:16:a1
	    Hostname (12), length 7: "Gauche2"
	    FQDN (81), length 10: "Gauche2"
	    Vendor-Class (60), length 8: "MSFT 5.0"
	    Parameter-Request (55), length 15: 
	      Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
	      Router-Discovery (31), Static-Route (33), Vendor-Option (43), Netbios-Name-Server (44)
	      Netbios-Node (46), Netbios-Scope (47), Unknown (119), Classless-Static-Route (121)
	      Classless-Static-Route-Microsoft (249), Unknown (252), URL (114)

It (the DHCP client, so my PC DHCP client) did tell the DHCP server it's name was "Gauche2" (option 81) and that length is "10", that's 3+7 = 10.

marcosm

Kea 3.2.0 will be in the next pfSense release.