Some devices randomly losing their IPv4 address

Thu Apr 7 00:10:10 UTC 2022

Glenn,

On Wed, Apr 6, 2022 at 4:16 AM Glenn Satchell <glenn.satchell at uniq.com.au>
wrote:

> Hi Julien
>
> My guess about losing an address is that you have a race between dhcp
> servers, and the client gets to pick which response to use, usually the
> first it receives. So if your router gets the response in first, the the
> client gets a message about no free addresses. If your dhcp server
> system wins, then the client gets the IP address. I can't see an easy to
> way to solve this other than the workaround you tried.
>

Thanks for responding. I think you are right about the race condition.

I tried to force the problem to be reproduced yesterday, by setting both
DHCP server maximum lease time to just two minutes.
I saw many devices quickly drop off the IP I had setup in isc-dhcp-server.
Some came back, eventually, but others didn't.
The Unifi controller showed many of my TP-Link KP125 smartplugs switch to
their autoconfiguration IPv4 address starting with 169.254, for example.

I think the issue is that the devices always get an IP from DHCPv6 running
on the Comcast server. But due to the race, they sometimes get a "no IP
available" from the Comcast DHCPv4 server.
>From then on, some decide to give up on DHCPv4 altogether, and never try
DHCPv4 client requests again.
This isn't something I can fix, unfortunately. For my own single-board
computers, I might be able to figure out a workaround. But for IoT devices
with vendor firmware, I can't do anything about it.

Last night, I turned off my isc-dhcp-server, and re-enabled the Comcast
DHCP server.

With nothing but one computer connected to the router, I was able to
painstakingly add 85 DCP reservations. This took over an hour with the
awful UI. It looks like it did work, though.
Problems have arisen in the past when making changes, or when trying to
forget devices. The XB7 router's HTTP UI in the past came up with all kinds
of errors when trying to make changes to existing entries, and worst of
all, taking 2 minutes before returning the error when making a change. And
there was no way to delete entries at all through the router's UI. You had
to go to the xFi website to do so. Now, the xFi website itself has a notice
saying that it is going away, and is being replaced by an app on a
smartphone. Sigh. This is no way to manage a large network. Currently, I
have 85 devices. And 40 more smartplugs still boxed that I want to add,
that will bring it up to 125. I know I don't want to deal with the awful
Comcast router's UI to manage all the reservations. I think this really
calls for putting the XB7 in bridge mode, and using a separate router. I'm
not sure what to use, though. I downloaded IPFire yesterday and put it on
an SD card. I don't know if the Raspberry Pi 4B will be fast enough - I
would like it to handle at least gigabit download speed. I have a pair of
Realtek USB 2.5Gbase-T NICs, but my experience with them hasn't been good -
they can't do full-duplex 2.5 Gbps in iperf even on a full-fledged powerful
PC because they are limited by USB 3.0.  On the Pi, the situation is
probably going to be worse. But maybe since the Comcast Internet service is
half duplex (1400/35) this will work out. At least with a single NIC, the
Pi can probably handle that. I'm not sure about two such 2.5Gbase-T NICs in
one Pi, which are required for a router.

Julien

>
> A few notes about your dhcpd.conf, but I don't think this will help...
>
> You definitely want this set:
>
> # If this DHCP server is the official DHCP server for the local
> # network, the authoritative directive should be uncommented.
> authoritative;
>
> You don't need the deny here, because everything that is not allowed is
> already denied:
>
> pool {
>   allow unknown-clients;
>   # deny known-clients;
>   range 192.168.1.101 192.168.1.200;
> }
>
> The group should be defined outside the subnet, and it doesn't need the
> deny either, because only specific devices are matched by the mac
> address. actually you don't even need the group - all the host
> statements can go in the top level.
>
> # known clients
> group {
>   # deny unknown-clients;
> ...
> } # end of group
>
> In general the dhcpd.conf man page is a wealth of information.
>
> regards,
> Glenn
>
> On 2022-04-06 07:48, Julien Pierre wrote:
>
> > 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
> --
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20220406/ed12143b/attachment-0001.htm>