Kea DHCP Server config changes not applied until reboot

KB8DOA

v24.11

I am finding that changes to
Server Options - DNS Servers,
and
DHCP Static Mappings
are not getting applied to Kea DHCP Server UNTIL I reboot pfSense+.

Restarting the DHCP Service does not help - a reboot is the only way the changes will take effect.

Has anyone else seen this?

Ramosel

@KB8DOA
I think that is what I'm seeing as well... but I don't want to eat up your thread on my speculation. I'll be posting my request for help/bug report as soon as I finish typing it.

Rick

Update: YES, that did resolve my issue with KEA DHCP this weekend. I mentioned you in my post of this morning. Thanks for posting this and your timing was spot-on!

patient0

@KB8DOA I'm running 24.11 with KEA for some time and did not notice that.

Are the client(s) not picking up the reservation? If yes what are the lease times?
Does reboot the client help? And I assume the static reservation is outside of the DHCP pool?
Applied any or all available patches for 24.11 (if not install the System_Patches package)

For testing I just booted up a client and set a DHCP reservation. Took the interface on the client down and up again. Voila, the assigned IP was handed out. The lease time is set to 3600 for that LAN.

KB8DOA

@patient0

Now - go and change that client's reserved IP address and watch as the client will not pick up the change after you save it...

Default DHCP time.

Reboot of client, it just gets issued the old IP address.

Yes - the reservation is outside the Static Pool.

Patches? Really?
I keep running update - and all seems updated.

If there is something specific to KEA DHCP in the patches, I am willing to apply the patches.

Best Practice is to keep the updates current and not to apply patches unless specific fix is needed.

However this is common DHCP operation, which I would expect has been fixed in an update - not a "patch"...

Ramosel

@KB8DOA There was one patch related to KEA and I applied that weeks ago. It had no impact on the problem I had this weekend or the issue you are working on.

Rick

patient0

@KB8DOA said in Kea DHCP Server config changes not applied until reboot:

Now - go and change that client's reserved IP address and watch as the client will not pick up the change after you save it..

Did change the reservation and the client picket it up, it does work for me.
From dynamic (.102, range .100 - .199) to static mapping (.78) to another static mapping (.40). For the last change it took a minute or so after the link up on the client.

KB8DOA

@patient0

I will try applying the patches tonight when I reboot the pfsense.

KB8DOA

@KB8DOA

No patches avail:

Ramosel

@KB8DOA
The one patch I found for Kea was for the plus version 24.11. I had applied it a week or so back. Made no difference in my issues last night and today.

Fix Kea failure with per-pool settings for Default or Maximum Lease Time (If this patch offers both Apply and Revert actions, do not Revert, Redmine #15332)

Bill Meeks left an informative note on my issue about significant differences between the Kea versions for CE and Plus. But even those differences didn't make Kea work for my problem. Thanks for posting on the reboot. That is the only thing I could do to fix my issue.

SteveITS

@KB8DOA There should be a lot. Did you update the patches package?

Gertjan

@KB8DOA said in Kea DHCP Server config changes not applied until reboot:

Restarting the DHCP Service does not help - a reboot is the only way the changes will take effect.

cat  /usr/local/etc/kea/kea-dhcp4.conf

and hit execute.

Keep te screen open, and open another pfSense GUI, and go to the DHCPv4 settings pages.

Now : compare.

Most, if not all, what is shown in the file is easy to understand.

The (your) question : what setting is present in the GUI that you can't find in the config file ?

KB8DOA

@Gertjan

I am not saying that the conf file and GUI are different.
What I am saying is that the GUI/conf changes do not get applied until I reboot pfSense.

I have verified, and the changes I made are already in the conf file.
Also - just to clarify - I am using the default DHCP Lease time.

2 examples:

Change DNS Servers for an interface:

the devices on that interface keep renewing for weeks and are still using the old DNS Servers...
upon rebooting, all the devices will start using the new DNS Servers.

Assign Static Mapping of IP:

the device will continue to keep renewing and using the default ip address assigned from the Pool for weeks...
upon rebooting, the device will start using the Static IP Address that has been assigned to it.

KB8DOA

Had it happen again.

After rebooting pfSense+, the DHCP server finally issued the correct IP Address to the DHCP Client.

Does anyone else want me to try something?

KB8DOA

@Ramosel

You are welcome.

I am going to start looking into going back to ISC DHCP.

Even though it is EOL, at least it is not Beta...

Gertjan

@KB8DOA said in Kea DHCP Server config changes not applied until reboot:

Had it happen again.

If you have some spare moments, run this while using ISC, and Kea :

and hit the start button.

You'll see the DHCP "client" requests in real time, the ones reaching your pfSense DHCP server, and the DHCP server answers.

manicmoose

@Gertjan @KB8DOA
FWIW, I see similar behaviour on 2.8.0.
I have not tried rebooting yet (my family will kill me) but my client does not get the reserved IP address I have set for it in Kea. It gets everything else.

The entry in "/usr/local/etc/kea/kea-dhcp4.conf" (correctly) shows:

                    {
                        "hw-address": "be:a7:d5:41:83:0b",
                        "ip-address": "192.168.99.96",
                        "hostname": "newclient",
                        "option-data": [
                            {
                                "name": "domain-name",
                                "data": "localdomain"
                            },
                            {
                                "name": "domain-search",
                                "data": "localdomain"
                            },
                            {
                                "name": "domain-name-servers",
                                "data": "1.0.0.1, 9.9.9.9"
                            }
                        ]
                    },

I packet-captured the DHCP, and it appears to be doing all the right things except handing out the wrong IP:

21:21:26.759427 be:a7:d5:41:83:0b > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from be:a7:d5:41:83:0b, length 548, xid 0x4854577, Flags [none] (0x0000)
	  Client-Ethernet-Address be:a7:d5:41:83:0b       <---- This IS the correct MAC for the client.
	  Vendor-rfc1048 Extensions
	    Magic Cookie 0x63825363
	    DHCP-Message (53), length 1: Request
	    Requested-IP (50), length 4: 192.168.99.100    <----WRONG IP -  this is the first IP in the DHCP range.
	    MSZ (57), length 2: 576
	    Parameter-Request (55), length 8: 
	      Subnet-Mask (1), Default-Gateway (3), MTU (26), Unknown (252)
	      NTP (42), Domain-Name (15), Domain-Name-Server (6), Hostname (12)
	    Client-ID (61), length 7: ether be:a7:d5:41:83:0b   <---- Again, the correct MAC for the client.
	    Hostname (12), length 3: "newclient"    <---- Correct DNS name for the client, as defined in the DHCP server entry.
21:21:26.767520 00:0e:c4:d2:06:1f > be:a7:d5:41:83:0b, ethertype IPv4 (0x0800), length 338: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 324)
    192.168.99.1.67 > 192.168.99.100.68: [udp sum ok] BOOTP/DHCP, Reply, length 296, xid 0x4854577, Flags [none] (0x0000)
	  Your-IP 192.168.99.100          <---- WRONG IP
	  Client-Ethernet-Address be:a7:d5:41:83:0b
	  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.99.1
	    Domain-Name-Server (6), length 8: 1.0.0.1,9.9.9.9    <--- This IS correct, and SPECIFIC for this client, so I know 'part' of Kea is working/responding correctly
	    Hostname (12), length 3: "newclient"    <--- This IS correct, and SPECIFIC for this client
	    Domain-Name (15), length 11: "localdomain"  <--- This IS correct, and SPECIFIC for this client
	    Lease-Time (51), length 4: 86400
	    Server-ID (54), length 4: 192.168.99.1

The "dhcp.log" also shows the wrong IP:

Aug  8 21:42:32 fw kea2unbound[940]: Record installed: "100.99.168.192.in-addr.arpa. 28800 IN PTR newclient.localdomain."
Aug  8 21:42:32 fw kea2unbound[940]: Record installed: "newclient.localdomain. 28800 IN A 192.168.99.100"
Aug  8 21:42:32 fw kea2unbound[940]: Include updated: /var/unbound/leases/leases4.conf (3575f494a69dc0df)
Aug  8 21:42:32 fw kea2unbound[940]: Syncronization completed: 113.7891ms

Ignore that the times in the 2 logs are slightly different - I tried multiple times - the logs were the same.

¯\_(ツ)_/¯

The same client used to work fine with ISC every time, for years.

edit
Reverted back to ISC, rebooted the client. BAM. Correct IP.
Kea is definitely buggy.