Kea DHCP Server config changes not applied until reboot
-
@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. -
I will try applying the patches tonight when I reboot the pfsense.
-
No patches avail:
-
@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.
-
@KB8DOA There should be a lot. Did you update the patches package?
-
@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.confand 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 ?
-
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.
-
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?
-
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...
-
@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.
-
@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.1The "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.7891msIgnore 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.
