Project

General

Profile

Actions

Bug #15966

open

Kea DHCP - Changing Deny Unknown Clients from Allow Known to Unknown Requires Reboot

Added by Steven Cedrone about 1 month ago. Updated about 1 month ago.

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

0%

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

Description

Changed DHCP "Deny Unknown Clients" from " Allow Known..." to "Allow All" caused the service to stop answering requests from clients

Reboot corrects the issue. Restarting the DHCP Service does not.

From System >> DHCP Log:

Jan 3 06:51:19 kea-dhcp4 40726 WARN [kea-dhcp4.alloc-engine.0x1e3238e16d00] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1 e2:fb:b4:96:96:b4], cid=[01:e2:fb:b4:96:96:b4], tid=0xfbb83d3a: Failed to allocate an IPv4 address for client with classes: ALL, pool_lan_0, pool_opt2_0, pool_opt3_0, pool_opt4_0, pool_opt6_0, pool_opt10_0, UNKNOWN

Jan 3 06:51:19 kea-dhcp4 40726 WARN [kea-dhcp4.alloc-engine.0x1e3238e16d00] ALLOC_ENGINE_V4_ALLOC_FAIL_NO_POOLS [hwtype=1 e2:fb:b4:96:96:b4], cid=[01:e2:fb:b4:96:96:b4], tid=0xfbb83d3a: no pools were available for the address allocation

Jan 3 06:51:19 kea-dhcp4 40726 WARN [kea-dhcp4.alloc-engine.0x1e3238e16d00] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1 e2:fb:b4:96:96:b4], cid=[01:e2:fb:b4:96:96:b4], tid=0xfbb83d3a: failed to allocate an IPv4 lease in the subnet 192.168.33.0/24, subnet-id 8, shared network (none)

Actions #1

Updated by Lev Prokofev about 1 month ago

Not able to replicate, tested on

24.11-RELEASE (amd64)
built on Wed Nov 20 13:41:00 -04 2024
FreeBSD 15.0-CURRENT

1)Set Deny Unknown Clients to "Allow known clients from only this interface"
2)Save
3)Set Deny Unknown Clients to "Allow all clients"
4)Save

the client is able to get the IP.

Actions #2

Updated by Steven Cedrone about 1 month ago

Lev Prokofev wrote in #note-1:

Not able to replicate, tested on

[...]

1)Set Deny Unknown Clients to "Allow known clients from only this interface"
2)Save
3)Set Deny Unknown Clients to "Allow all clients"
4)Save

the client is able to get the IP.

I'm able to reproduce. I'm, on PfSense+ latest version... 24.11

Actions #3

Updated by Jim Pingle about 1 month ago

  • Status changed from New to Incomplete

Sounds more like something is keeping your daemon from reloading with the new settings, not a bug specific to that particular option. There have been a couple reports of similar issues but nothing definite and repeatable has been identified thus far.

Please post on the forum for assistance, or contact TAC if you have a subscription.

Actions #4

Updated by Steven Cedrone about 1 month ago

Jim Pingle wrote in #note-3:

Sounds more like something is keeping your daemon from reloading with the new settings, not a bug specific to that particular option. There have been a couple reports of similar issues but nothing definite and repeatable has been identified thus far.

Please post on the forum for assistance, or contact TAC if you have a subscription.

Jim,

Not sure how that isn't a bug then. I have a standard setup, nothing fancy with regards to the network using the DHCP server. I have changed this setting before in older CE versions when I need a temporary client on an otherwise locked down network. I really think there is a lot of gremlins with KEA still because I find weird stuff like this since the move from the old DHCP server before KEA.

But whatever, a reboot fixes it. So hopefully my post helps someone else scratching their head and seeing nonsense in their logs.

I upgraded to PfSense Plus some time ago to support Netgate staff not because I need the Tac Subscription but to pay for the work I know that goes into this is a lot and I appreciate the contributions upstream to BSD as well and I don't believe in freeloading. I prefer to use my own hardware because I can customize it.

Regards, and Happy New Year.

Actions #5

Updated by Jim Pingle about 1 month ago

It's not a bug with this setting as stated, and there isn't enough information here to identify what that actual underlying bug might be, hence it being incomplete and the need for additional troubleshooting. And Redmine isn't the place for that discussion and diagnosis to happen.

If we can identify the underlying issue and replicate it in a lab setup, we can either adjust this or open a new issue with more accurate information.

Actions #6

Updated by Steven Cedrone about 1 month ago

Jim Pingle wrote in #note-5:

It's not a bug with this setting as stated, and there isn't enough information here to identify what that actual underlying bug might be, hence it being incomplete and the need for additional troubleshooting. And Redmine isn't the place for that discussion and diagnosis to happen.

If we can identify the underlying issue and replicate it in a lab setup, we can either adjust this or open a new issue with more accurate information.

So making a change like a normal user would do that then stops clients from getting IP addresses until the firewall is restarted, when this never happened before the implementation of the still known to be buggy KEA-DHCP server, isn't a bug and should be posted on a forum instead.

Got it. Didn't realize that bugs had to be classified as actual bugs before being reported as bugs even though they look like and act like bugs.

Cheers, I won't report any more critters until someone else reports them because apparently you can't re-create it in a lab so it must not exist in the wild.

Alrighty then. Off to do more important things than try to help.

Actions #7

Updated by Jim Pingle about 1 month ago

The issue is we do not have enough information to act on anything stated here. I'm not saying it didn't happen, or there isn't a problem, I'm saying you're likely chasing a symptom of a root cause that has not yet been sufficiently identified. We can't replicate the problem so we have no leads on how to address it without more data.

To find that root cause we need to diagnose the problem in more detail and find a way to replicate the problem. This issue tracker is not a discussion platform suitable for that process, the forum is.

Actions

Also available in: Atom PDF