KIA Really buggy, horrible. Having to switch to ISC

khris2fer

So I've had the worst luck with kia dhcp... very buggy, giving errors when I can't see why. There's no conflicts that I can see and no overlapping.. there's plenty of ip's in each pool/vlan. It won't give a dhcp address on any new device that connects to the network wired or wireless. The static mappings I thought were ok but I had an issue with one of those tonight it wouldn't give the ip.

I created another vlan and started moving everything over to that vlan cause this was only happening on 1 vlan.. but now it's happening on the new vlan too lol. I finally gave up and reverted to ISC and now so far I'm not having any issues. Has anyone else had to do this and if so is there anything to be concerned about being on the old option? I made a backup before switching I guess we'll see what happens.

Also I keep seeing where it's said to check for conflicts and overlapping..... if that were possibly the case or if that was happening switching back to ISC wouldn't fix that I wouldn't think would it? A conflicting ip or mac address would be an issue using either I would think but switching has fixed everything so far which I believe it to be KIA hasn't matured yet and still sucks. Either I hope it's better in the next release and or ISC is in the next release as well to fall back on if need.

I'm running 2.8.1 on a Protectli vault 2 port Here's one of the errors I was getting

WARN [kea-dhcp4.alloc-engine.0x1d7af815f00] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 bc:32:19:d8:98:c9], cid=[no info], tid=0x491d466a: conflicting reservation for address 192.168.50.14 with existing lease Address: 192.168.50.14 Valid life: 86400 Cltt: 1785434829 Hardware addr: Client id: (none) Subnet ID: 8 Pool ID: 0 State: declined Relay ID: (none) Remote ID: (none) User context: { "Netgate": { "option-data": { "domain-name": "home.arpa" } } }

Since switching to ISC Not one single problem. Anyone else going through this?

KOM

@khris2fer I tried KEA awhile back and it was crap so I reverted back to ISC just like you.

khris2fer

@KOM I don't understand how something that's suppose to be an upgrade and better can be such crap. I sure hope they don't do away with ISC until it's fixed

KOM

@khris2fer I agree and think Netgate should remove that scare-mongering message until KEA becomes usable. As it is now, EOL means that ISC isn't developing it anymore. They say they will not add features but will address any security flaws. Years later there have been none found that anyone is aware of. I will continue to use ISC DHCP on my LAN for this reason.

Gertjan

@khris2fer said in KIA Really buggy, horrible. Having to switch to ISC:

WARN [kea-dhcp4.alloc-engine.0x1d7af815f00] ALLOC_ENGINE_V4_DISCOVER_ADDRESS_CONFLICT [hwtype=1 bc:32:19:d8:98:c9], cid=[no info], tid=0x491d466a: conflicting reservation for address 192.168.50.14 with existing lease Address: 192.168.50.14 Valid life: 86400 Cltt: 1785434829 Hardware addr: Client id: (none) Subnet ID: 8 Pool ID: 0 State: declined Relay ID: (none) Remote ID: (none) User context: { "Netgate": { "option-data": { "domain-name": "home.arpa" } } }

Isn't this :
Kea received a "DHCP Discover", and the client device doing the discover suggested that it would like to have "192.168.50.14".
Kea informs the device that that lease is already take (in use). It can check this doing two things : looking it (IPv4) up into it's own leases file, and found that it's already assigned with a none expired lease time to another device == another MAC addresses.
It said it found a lease :

@khris2fer said in KIA Really buggy, horrible. Having to switch to ISC:

existing lease Address: 192.168.50.14 Valid life: 86400

(I bet with another MAC address)

And/or even 'worse' : Kea executes a 'arp' request on the LAN where the DHCP came from and it got a reply back form a device saying "I'm using 192.168.50.14 right now" (could also be a device using 192.168.50.14 with static IP setup ?).

This could be a device that has a valid lease, then forgot all about it, (like : it had reset it's wifi interface because the connection went down an instant) and requested a new lease = DHCPDISCOVER instead of a simple DHCPRENEW, and here is where it could fail : it regenerated another random MAC, and that totally broke RFC : it still requested the same IP as before, but it kept the initial IP.
What can de DHCP server do ? What would you do ? => replying : sorry, IP already occupied.
Solutions :
For devices that you trust, like your won phone, on your trusted LAN : switch off MAC randomizing.
Use a device with a less broken DHCP support ^^

I will and can not say that kea has no issues/bugs.
kea is build by the same guy(s) as ISC, so they should be aware of what needs to be done to make it work.
kea dhcp server is right now serving billions of leases per second, as more and more ISC instances are being replaced by kea on all very small and very big systems.
pfSense uses the compiled/build FreeBSD open source tree.
pfSense, the GUI, does basically just one thing : it creates the config file for kea, and starts stops kea when needed.

I really think it's worth finding out what so different with your 'unique' setup, more probably your device(s), and you will find the solution/answer.
I use kea myself for my own private LANs, and also a public LAN = a captive portal, where god knows what devices are thrown at it.

When I have a look at my Status > System Logs > DHCP is see 10 days of DHCP logging.
3 things stand out :
No ERRORS at all.
99 % of the logging is the DHCP6v service :

and ones in a while, a device, using DUID "00:03:00:01:02:51:ae:8f:b1:c5" request a IPV6 lease and it fails as the format of the DHCPv6 request is wrong. This will produce a WARN :

It's the phone of college, a low bud 'AliExpress' android device doing DHCP IPv6 ....

I create my own IPv4 leases-log file (see this forum how to do so) as the pfSense Kea implementation doesn't log succeeding leases anymore :

I guess I understand now why Netgate decide not to log these messages anymore : it's boring.

Anyway .. just saying : DHCP isn't that hard, and the core issue could be found. I think it's worth it doing so.

Bob.Dig

@khris2fer said in KIA Really buggy, horrible. Having to switch to ISC:

I don't understand

I don't understand what pfSense has to do with a car.

AndyRH

@Bob.Dig I think you are confusing the "Killed In Action" cars with the "Kill Every Afternoon" DHCP server.

I have also had no issues with KEA. As said before chasing the error will likely end with either, "Well nuts, there it is" or "That's weird, I need to report it." Until the actual cause is found you cannot say it is or is not a KEA problem.