Send dhcp-users mailing list submissions to
dhcp-users@lists.isc.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
dhcp-users-requ...@lists.isc.org
You can reach the person managing the list at
dhcp-users-ow...@lists.isc.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Some devices randomly losing their IPv4 address
(Kenneth Porter)
2. Re: Some devices randomly losing their IPv4 address
(Glenn Satchell)
----------------------------------------------------------------------
Message: 1
Date: Tue, 05 Apr 2022 20:35:37 -0700
From: Kenneth Porter <sh...@sewingwitch.com>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Some devices randomly losing their IPv4 address
Message-ID: <28FB70FA36A6DA744A011937@[192.168.69.69]>
Content-Type: text/plain; charset=us-ascii; format=flowed
--On Tuesday, April 05, 2022 8:03 PM -0700 Julien Pierre
<goldberg.variati...@gmail.com> wrote:
> Thanks. I hadn't heard of the Kea DHCP server. I just checked the
> description, and it looks like something I want to try.
I used the Kea migration assistant utility, keama, to convert my ISC config
file to a JSON Kea config file. It seemed to do a good job. I thought at
first I'd want to convert my lease file, and started to invest some coding
towards that, but realized I didn't really care if the dynamic devices got
different addresses.
I did run into the problem that I didn't want DDNS for my reserved devices,
as I gave them DNS names statically in my BIND9 zone files. More details
and how I worked around it here:
<https://gitlab.isc.org/isc-projects/kea/-/issues/2354>
> I was on the Gigabit tier not because I needed the highest download
> speed, but because that's the only way to get their maximum upload speed,
> which is a paltry 45 Mbps.
That makes perfect sense. Some of us care about the upload bandwidth.
> I have been waiting 12 years
> for AT&T to lay it. I don't think it's ever happening on my side of the
> hill.
I know what you mean. My office was stuck in ADSL hell for a very long time
before another building tenant had fiber run in, and we were able to
piggyback on the main feed for that.
It sounds like you don't really need a router capable of the full 1.2 Gbps,
as long as it can keep up with the 45 Mbps upstream. I'm hearing on the
bufferbloat mailing list that a lot of consumer routers can still keep up
with a half Gbps in each direction.
> Thanks, I hadn't thought of that. I don't have access to the logs for many
> of the devices on which this happened, which are off-the-shelf Wifi
> devices. For the single-board computers, I do have access, I'm going to
> look into it. I didn't write down the time for previous events, though.
>From experience, the first thing I put in trouble tickets is the timestamp,
so the other guy can correlate it with his logs. The first thing I do when
I see a problem is to list /var/log in date order to see which files got
touched recently.
------------------------------
Message: 2
Date: Wed, 06 Apr 2022 21:16:03 +1000
From: Glenn Satchell <glenn.satch...@uniq.com.au>
To: Users of ISC DHCP <dhcp-users@lists.isc.org>
Subject: Re: Some devices randomly losing their IPv4 address
Message-ID: <795f7d9bbfbdb8bb40970124ef6d4...@uniq.com.au>
Content-Type: text/plain; charset=US-ASCII; format=flowed
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.
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
------------------------------
Subject: Digest Footer
_______________________________________________
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 162, Issue 2
******************************************
