After more googling I figured this out, the dhcp4 setting for interfaces-config, dhcp socket type was set to UDP which was suggested in one of the guides I referenced (among may) for setting this up, turns out this was the blocker. Changing this to raw fixed it for me.
> On Feb 5, 2026, at 10:23 AM, [email protected] wrote: > > I have Kea set up in a Lab environment, about 100 subnets, using DHCP > helpers/relay to redirect traffic from other subnets to the DHCP server. All > of that is working great. But I just found out that if a system on the same > switch, in the same subnet as the DHCP server, attempts to get a DHCP > address, that request is ignored by Kea. > > My original assumption was some network issue, but I used tcpdump to watch > for traffic from the client's MAC address and I saw packets hitting the DHCP > server. But nothing matching the MAC address of the client was logged by > Kea, and no reply traffic was ever sent. MAC below slightly obfuscated. > > [root@dhcp-2 kea]# tcpdump -vv -e ether host 11:22:74:25:e1:90 > dropped privs to tcpdump > tcpdump: listening on eno16895np0, link-type EN10MB (Ethernet), snapshot > length 262144 bytes > 10:14:37.975470 11:22:74:25:e1:90 (oui Unknown) > Broadcast, ethertype IPv4 > (0x0800), length 342: (tos 0x0, ttl 128, id 1879, offset 0, flags [none], > proto UDP (17), length 328) > 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request > from 8c:84:74:25:e1:90 (oui Unknown), length 300, xid 0x65cbc874, secs 12, > Flags [Broadcast] (0x8000) > Client-Ethernet-Address 8c:84:74:25:e1:90 (oui Unknown) > Vendor-rfc1048 Extensions > Magic Cookie 0x63825363 > DHCP-Message (53), length 1: Discover > Client-ID (61), length 7: ether 8c:84:74:25:e1:90 > Hostname (12), length 15: "WIN-SUC50U6GFQI" > Vendor-Class (60), length 8: "MSFT 5.0" > Parameter-Request (55), length 14: > 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) > > And nothing in the Kea log: > > [root@dhcp-2 kea]# cat /var/log/kea/kea-dhcp4.log | grep e1\:90 > [root@dhcp-2 kea]# > > > My subnet definitions list each subnet here, including the subnet > (Infrastructure) that the DHCP server and the client in question are in, IPs > below obfuscated > > "subnet4": [ > > //Infrastructure > { "id": 192168010, > "subnet": "192.168.10.0/24", > "pools": [ { "pool": "192.168.10.200 - 192.168.10.220" } ], > "option-data": [ { "name": "routers", "data": "192.168.10.254" } ] }, > > //Bench > { "id": 192168002, > "subnet": "192.168.2.0/23", > "pools": [ { "pool": "192.168.3.50 - 192.168.3.249" } ], > "option-data": [ { "name": "routers", "data": "192.168.2.1" } ] }, > > > Two questions at this point, why isn't Kea logging anything regarding the > Discover request that is being ignored? If it couldn't be processed, > something should be logged? Second question, how to fix things so that Kea > can give the client in the Infrastructure subnet an IP? > -- > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > [email protected] -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. [email protected]
