Some devices randomly losing their IPv4 address

Tue Apr 5 21:48:18 UTC 2022

I am very new to running the isc DHCP server. I started running it on my
Raspberry Pi 4B a few weeks ago in an attempt to work around problems with
my Comcast XB7 router's built-in DHCP server. The issue is that my router's
user interface to control the built-in DHCP server has numerous bugs
setting DHCP reservations for a large number of devices, and I have 80 of
them. I believe the problems with that server start around 64 devices, and
I have over 80 of them. I need reservations for my devices in order for
HomeAssistant to work - it needs fixed IP addresses. Also, I use smokeping
for monitoring my devices, and it also requires fixed IP addresses.

Unfortunately, the Comcast router's built-in DHCP server cannot be
completely turned off. The only thing I can do is shorten the range for its
DHCP range, which I have done for its DHCPv4 server. Its DCHPv6 server
cannot be disabled, as far as I can tell.

In an ideal world, I would just switch the XB7 router to bridge mode, and
use a separate wired router, with working DHCP servers, and be done with
it. The main reason I haven't done exactly that comes down to the fact that
I have multi-gig service, and can't find an off-the-shelf wired router to
do the job. The XB7 has a 2.5GBASE-T LAN interface. I would need a router
that has both 2.5GBASE-T LAN and WAN interfaces. I haven't found one, so
far. I would need to build one myself, and it would come at significant
cost, both in terms of hardware and additional power consumption, not to
mention how much unwanted noise it might have, whereas the Comcast XB7 is
silent.

So, instead of having a separate router, I have been running both the XB7
DHCP server, and the isc-dhcp-server on my Raspberry Pi 4B in parallel on
the same LAN, hoping to work around the XB7 DHCP server limitations.

I setup the Comcast router's DHCP server to serve only the 192.168.1.2 to
192.168.1.3 IPv4 range. The .2 address has a reservation for my Raspberry
Pi 4B. The .3 address has a reservation for the primary desktop on my LAN.

I setup the ISC DHCP server in DHCPv4 mode only. There is a group
containing reservations for my other devices in the .4 through .100 range,
and a dynamic pool from .101 through .200 .

This has mostly worked for the last few weeks, except for one major issue :
once in a while, some devices lose their IPv4 addresses. I know this from
running smokeping on my Pi 4B against all the devices with IPv4 addresses
reservations, and seeing the devices disappear in the recorded data. Also,
from not being able to access some devices.

For example, this morning at 5:30am, while I was asleep, my Pi 3B running
HomeAssistant (HAOS) lost its IPv4 address. When I woke up, I unplugged its
Ethernet cable, and plugged it back in, and that fixed the problem - it
acquired an IPv4 address again. Unfortunately, that means device
automations didn't run in the meantime, including the ones collecting data
from my Rainforest SmartMeter gateway, and since that automation only works
in real-time, data from the meter has been lost. The Pi 3B is not the only
device to which this has happened. I have seen a few others do this as
well, my Odroid XU4 and N2+ running Ubuntu for example.

I haven't found a pattern as to why some devices are losing their IPv4
address and not others, or when. Some devices never do. The issue doesn't
happen at the same time for all devices. I know it's not related to device
reboot, though. The clients aren't rebooting when the issue shows up. And
the Pi4B and isc-dhcp-server are up when the issue happens, as they were
this morning. They are on UPS also, and it's not a power outage issue - I
would know about it. I am hoping experts on this list can shed some light
on what might be going here and suggest possible changes.

Here is what my ISC DHCP server configuration looks like :

# dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#

# option definitions common to all supported networks...
option domain-name "test.local";
# option domain-name-servers ns1.example.org, ns2.example.org;
option domain-name-servers 8.8.8.8, 8.8.4.4;

default-lease-time 7200;
max-lease-time 86400;

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;

# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
#log-facility local7;

option routers 192.168.1.1;

subnet 192.168.1.0 netmask 255.255.255.0 {
# unknown clients
    pool {
        allow unknown-clients;
        deny known-clients;
        range 192.168.1.101 192.168.1.200;
    }
# known clients
group {
        deny unknown-clients;

# NanoHD Office
host ap1 {
hardware ethernet (hidden)
fixed-address 192.168.1.4;
}

# ... other reservations follow here

  } # end of group
} # end of subnet

Here is the "local IP network" configuration for the Comcast router :

IPv4 :
Gateway address : 192.1681.1.1
Subnet mask : 255.255.255.0 . This is a drop-down, and the only other
option available is 255.255.255.128 .
DHCP beginning address : 192.168.1.2
DHCP ending address : 192.168.1.3
DHCPv4 lease time : 2 days (this always resets to 2 days upon reboot)

IPv6 : link-local address : address starting with fe80 : 0 :0 : 0
Global gateway address : address starting with 2601
LAN ipv6 address assignment :
Stateless (auto-config) : checked . This is greyed out and cannot be turned
off.
Stateful (use DHCP server) : unchecked
DHCPv6 beginning address  : address starting with 2601 and ending with
0001, /64
DHCPv6 ending address  : address starting with 2601 and ending with fffe,
/64

Thanks for any help in advance !
Julien
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220405/4540923d/attachment.htm>