[Kea-users] Kea DHCP not replying to Source Address 0.0.0.0

[Jim]

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, jim at wrightthisway.com 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 at 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 at dhcp-2 kea]# cat  /var/log/kea/kea-dhcp4.log | grep e1\:90
> [root at 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.
> Kea-users at lists.isc.org