Kea DHCPv4: failed to select a subnet for incoming packet, on specific devices

Gertjan

@johnpoz said in Kea DHCPv4: failed to select a subnet for incoming packet, on specific devices:

from a linklocal 169.254 address.. I just block it at the switch port, its noise.. maybe they use 169 when looking for other brother sort of devices, etc..

What happened to the most obvious question : IP starts with 169.254 ?

An IP address beginning with 169.254 is called an Automatic Private IP Addressing (APIPA) IP address. APIPA is a feature in operating systems that allows a device to automatically assign itself an IP address if it can't get one from a DHCP server.

So, if it had a valid lease before, it would renew - and this part is shown no where the logs, failed (like pfSense never received this sequence), and the device assigned itself an APIPA as a last resort.
Wouldn't that explain the subsequent "failed to select a subnet for incoming packet" ?
Because this event isn't logged, the initial failing DHCP sequence that lead to the APIPA : is the network any good ? Like broken switch or cable or NIC ?

johnpoz

@Gertjan no there is no leading to apipa - these devices use link-local even though they have an IP..

Here is my directv stuff doing it. Even though it has an IP 192.168.7.6 it still spams the network with ssdp from a 169.x address

Gertjan

@johnpoz

Ok, thanks for the info.
I wasn't even aware of this 'SSDP' (port 1900, UDP) spamming.
A quick capture on my LAN showed me :

15:10:42.469724 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 400
15:10:43.499397 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 302
15:10:43.520079 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 302
15:10:43.540744 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 311
15:10:43.559250 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 311
15:10:43.579582 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 368
15:10:43.600737 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 368
15:10:43.619551 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 366
15:10:43.639326 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 366
15:10:43.660949 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 354
15:10:43.679581 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 354
15:10:43.699532 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 326
15:10:43.725349 IP 192.168.1.18.52761 > 239.255.255.250.1900: UDP, length 326
15:10:43.727386 IP 192.168.1.18.44038 > 239.255.255.250.1900: UDP, length 127
15:10:44.559311 IP 192.168.1.18.47973 > 239.255.255.250.1900: UDP, length 127

Lucky me, it's using its assigned LAN IP, note some fake 169. whatever IP.

Still, why on earth does a device has to spam 10+ of these packets per second ??

Btw : it's our 'back ground radio' .... I think about putting this one on it's own isolated network where it can yell as much as it wants without annoying the others .... and if I'm not happy afterwards => direction landfill ... sorry, 'recycled'.

johnpoz

@Gertjan yeah I filter stuff like that at the switch.. 10+ a second is insane.. I shut it down at the switch with my plex doing it once ever 10 seconds..

Wired at least with the right switch you can filter some of that noise, but if wireless your pretty much out of luck. And broadcast and multicast on wifi is not optimal for overall performance.

SteveITS

@Gertjan said in Kea DHCPv4: failed to select a subnet for incoming packet, on specific devices:

So, if it had a valid lease before, it would renew - and this part is shown no where the logs, failed (like pfSense never received this sequence), and the device assigned itself an APIPA as a last resort.
Wouldn't that explain the subsequent "failed to select a subnet for incoming packet" ?

That's the thing, the devices DO get a valid IP and do work. It doesn't have any way to set a static IP but it does have a "test" page showing it's connected.

Further, it seems these devices DO get a normal lease and renew it at the expected interval (the above log), so these triple log entries seem to be just noise.

On ISC, as I mentioned in my OP, the lease renewals for these devices happen every 10 minutes.

Ergo, something is different between how ISC DHCP handles whatever this is (renews the lease every 10 minutes) and Kea (logs this error).

So I guess my choice is to use Kea and ignore the errors, or use ISC DHCP and ignore the renewals. Six of one, half a dozen of the other. I use a RAM disk for logs so it doesn't really matter for disk wear, for me, but might for others, over time. If they have Dish hardware and pfSense. At least the logs are not that big.

-rw-------  1 root wheel 381876 Feb  4 09:15 dhcpd.log
-rw-------  1 root wheel 512503 Feb  4 05:08 dhcpd.log.0
-rw-------  1 root wheel 511538 Feb  3 23:44 dhcpd.log.1
-rw-------  1 root wheel 511959 Feb  3 18:15 dhcpd.log.2
-rw-------  1 root wheel 511354 Feb  3 12:48 dhcpd.log.3
-rw-------  1 root wheel 512587 Feb  3 07:23 dhcpd.log.4
-rw-------  1 root wheel 511842 Feb  3 02:00 dhcpd.log.5
-rw-------  1 root wheel 512745 Feb  2 20:30 dhcpd.log.6

johnpoz

@SteveITS said in Kea DHCPv4: failed to select a subnet for incoming packet, on specific devices:

(renews the lease every 10 minutes)

how long do you have lease set for? 10 minutes is pretty short, and say if your lease was 2 hours - dhcpd wouldn't normally renew that because its too early in the lease period.

SteveITS

@johnpoz It was set to I think 4 days when I started, and I changed it to the default 2 hours, meaning a 1 hour renewal.

On Kea these two devices renew every hour as expected but the error is logged every 10 minutes.

On ISC these two devices renew every 10 minutes, so it's processing whatever this request is instead of logging an error.

johnpoz

@SteveITS no way to set static on them? but yeah seen a lot of iot devices with shit stacks.. My old thermometer would get a IP from dhcp, and then never ever renew. And only way to change the IP on it was to forget the whole network on it.

SteveITS

@johnpoz no, I double checked last night. I think they just dumb it down for the masses, I mean their techs.

I've posted before but these have one other oddity...the DVR (AFAICT) uses DHCP assigned DNS. The "on demand" app it uses to stream movies requires its own DoH. Other apps like Netflix do not.

Gertjan

@SteveITS said in Kea DHCPv4: failed to select a subnet for incoming packet, on specific devices:

On ISC, as I mentioned in my OP, the lease renewals for these devices happen every 10 minutes.

That's the real issue.

A device generates a DHCP request.
The DHCP server answers with a lease, and a RFC compatible lease duration.
The thing is : the device doesn't give a #&@* and renews after 10 minutes using info (the 169.a.b.c) that isn't part of the network neither an existing lease.
Hence the "failed to select a subnet for incoming packet" message.

ISC : didn't complain about the erroneous client behavior and renewed.
kea : files an error.

And I persist : receiving a DHCP request initiated from 169.a.b.c IP (an IP or lease that kea never gave to this device) on a 192.168.1.0/24 network : kea will (and IMHO) should to complain about it.

johnpoz

@Gertjan said in Kea DHCPv4: failed to select a subnet for incoming packet, on specific devices:

And I persist : receiving a DHCP request initiated from 169.a.b.c IP

where are you seeing that - the 169 was sending ssdp, not dhcp.

Gertjan

Humm ....

This :

@SteveITS said in Kea DHCPv4: failed to select a subnet for incoming packet, on specific devices:

16:59:45.267678 IP 169.254.214.158.48563 > 239.255.255.250.1900: UDP, length 475
16:59:54.471731 IP 0.0.0.0.68 > 255.255.255.255.67: UDP, length 548

The second line seems like a valid DHCP request.
I was really thinking the first line rigged the failed to select a subnet for incoming packet but ... now obvious, it can / should not.

I guess I was talking faster as thinking

SteveITS

@Gertjan I copied the whole packet capture rather than cherry pick lines but it’s only the last 3 that trigger the Kea log error…the timestamps are exact. It just contains all UDP traffic from that MAC.