0

I am using a Raspberry Pi 3B running Pi-OS 10.13 (kernel 5.10.103-v7+).

I am running bind9 to provide DNS services for my LAN and isc-dhcp-server to provide DHCP services for my LAN.

The Pi is configured for a static IP address, 192.168.1.15, via the following in /etc/dhcpcd.conf:

interface eth0
static ip_address=192.168.1.15/24
static routers=192.168.1.1
static domain_name=<redacted>
static domain_name_servers=192.168.1.15 8.8.8.8 8.8.4.4
static domain_search=<redacted>

The DHCP server is configured to serve addresses from 192.168.1.32 to 192.168.1.254:

subnet 192.168.1.0 netmask 255.255.255.0
{
  range 192.168.1.32 192.168.1.254;
  option domain-name-servers 192.168.1.15;
  option domain-name "<redacted>";
  option domain-search "<redacted>";
  option routers 192.168.1.1;
  option broadcast-address 192.168.1.255;
}

The Pi has been working great in this capacity, with this configuration, for several years. Recently, however, I will wake up in the morning to find that it is off-line (taking my LAN down with it). Looking at the system log, it looks like another device (my Dish Network Hopper satellite receiver) is claiming its IP address, and the Pi's dhcpd and avahi-daemon processes then give up its address, even though it is statically configured.

From /var/log/syslog, I see the following at the time of the failure:

The Hopper (and the other Dish Network devices) all seem to be renewing their leases, getting the same address they always get:

Oct 25 04:52:50 pi dhcpd[2993]: DHCPDISCOVER from 28:57:67:3d:7a:d5 (Hopper2-ETH0) via eth0
Oct 25 04:52:51 pi dhcpd[2993]: DHCPOFFER on 192.168.1.247 to 28:57:67:3d:7a:d5 (Hopper2-br) via eth0
Oct 25 04:52:51 pi dhcpd[2993]: DHCPREQUEST for 192.168.1.247 (192.168.1.15) from 28:57:67:3d:7a:d5 (Hopper2-br) via eth0
Oct 25 04:52:51 pi dhcpd[2993]: DHCPACK on 192.168.1.247 to 28:57:67:3d:7a:d5 (Hopper2-br) via eth0

Then a flood of reuse_lease messages. The following appears 100 times, all within the same second:

Oct 25 04:52:51 pi dhcpd[2993]: reuse_lease: lease age 0 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.1.247
Oct 25 04:52:51 pi dhcpd[2993]: DHCPREQUEST for 192.168.1.247 (192.168.1.15) from 28:57:67:3d:7a:d5 (Hopper2-br) via eth0
Oct 25 04:52:51 pi dhcpd[2993]: DHCPACK on 192.168.1.247 to 28:57:67:3d:7a:d5 (Hopper2-br) via eth0

Then I see a bunch of router advertisements from the Pi's MAC address for its own IPv6 address. 10 copies of this message:

Oct 25 04:53:39 pi kernel: [245702.475006] ICMPv6: NA: b8:27:eb:02:cc:12 advertised our address 2601:5c9:4200:413f:c113:38b6:81e7:5cef on eth0!

Then, inexplicably, it appears that the Hopper tries to claim 192.168.1.15 (the Pi's Ethernet address), causing the Pi to give up its address and therefore go off-line:

Oct 25 04:53:44 pi dhcpcd[440]: eth0: hardware address 28:57:67:3d:7a:d9 claims 192.168.1.15
Oct 25 04:53:45 pi dhcpcd[440]: eth0: hardware address 28:57:67:3d:7a:d9 claims 192.168.1.15
Oct 25 04:53:45 pi dhcpcd[440]: eth0: 10 second defence failed for 192.168.1.15
Oct 25 04:53:45 pi avahi-daemon[25338]: Withdrawing address record for 192.168.1.15 on eth0.
Oct 25 04:53:45 pi avahi-daemon[25338]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.15.
Oct 25 04:53:45 pi avahi-daemon[25338]: Interface eth0.IPv4 no longer relevant for mDNS.

This problem happens intermittently. I can go anywhere between 1 and 7 days before the problem happens. And when it does, it is always early in the morning (between 4:00 and 5:00am).

What in the world could be going on here? And how can I fix this? If it's a case of the Hopper having buggy firmware (which may well be the case), is there a way I can block it from creating these problems?

As an experiment, I disabled Avahi (which seems to be what is disabling the interface), but that doesn't sound like a proper fix.

I originally had my DHCP lease times set to 24h (default) and 30d (max). Just in case that was causing tables to overflow, I just changed them to 12h (default) and 24h (max), to see if that will help.


Update: I just ran across This article, which is reporting similar symptoms from two years ago. Which makes me wonder if this is just a bug in dhcpcd. As a test, I'm reconfiguring the Pi to disable its DHCP client and instead get its static address via /etc/network/interfaces.


Update 2: After a few days, with the Pi configured for a real static address (and not a static dhcpcd configuration), I noticed the same flood of DHCP messages, from a new nodes on the network at about the same time as before - from 4:45 through 4:50. But since there is no local DHCP client to delete my local address, the device was able to ride out the flood. Apologies for the data-dump here, but I'm not sure if what I'm seeing is normal or indicative of a problem.

  • DHCP discover/offer/request/ack from Joey-MoCA (...:69) - a DISH Network STB, connected to the Hopper via MoCA, which bridges it to the home LAN. getting address 192.168.1.32
    • This looks perfectly normal, and I don't think it indicates a problem. But since it's happening at about the same time as the packet flood, I'm mentioning it here.
  • A sequence of DHCP communication from the Hopper
    • DHCP discover/offer/request/ack from the Hopper's Ethernet port, getting address 192.168.1.247
    • DHCP discover/offer/request/ack from the Hopper's Wi-Fi interface (via its internal bridge, I assume, since it's not actually connected to my Wi-Fi), getting address 192.168.1.185
      • This looks like a bug in the Hopper's firmware. But since its Wi-Fi is not configured and it reports as down, I'm not sure I can do anything about it.
    • Then another DHCP discover/offer/request/ack from the Hopper's bridge interface (same MAC as the Ethernet interface - I can only distinguish it because it is advertising a different name), getting the same address (192.168.1.247).
      • This looks like another bug in the Hopper's firmware. If the Hopper is trying to bridge all of its network interfaces, then the interfaces shouldn't be requesting distinct addresses - there should be one address for the bridge and nothing else.
    • Then a flood of DHCP reuse_lease/discover/offer/reuse_lease/request/ack messages. 19 instances of the sequence within the same second, all from the Hopper, getting its address.
  • Then I see a sequence of messages from another device in that room (an Apple TV), which seems to be rejecting several IP adresses offered to it before eventually settling on one:
    • Two DHCP decline messages from it, abandoning address 192.168.1.246.
    • Then DHCP discover/offer/request/ack, giving it a new IP address (191.168.1.239).
    • Then 27 reuse_lease/request/ack messages (for 192.168.1.246)
    • Then 243 DHCP decline/request messages from that Apple TV for the same IP address
  • Then a DHCP discover/offer from the Joey again, for the same 192.168.1.32 address
  • Then more traffic from the Apple TV (part of the previous flood, I assume):
    • DHCP discover/offer/request/ack to that Apple TV. This time with address 192.168.1.240
    • Then another flood of 8 reuse_lease/request/ack messages for the .240 address
    • Followed by a DHCP decline for that address
    • Then discover/offer/request/ack from it, this time getting 192.168.1.241
    • Then 9 reuse_lease/request/ack messages with that address
    • Then 3 DHCP declines for that address
    • Then a discover/offer/request/ack sequence, getting 192.168.1.229.
  • And that finally ends the packet flood. The logs after that point seem to look normal, without any massive floods of identical messages?

Is this something DHCP servers always deal with? Could it be a bug in my installation of isc-dhcpd? A bug in its configuration? Or is it responding properly to bugs in other devices on my LAN (apparently my Hopper and one of my Apple TVs)? Or maybe a reaction to a LAN issue (the Hopper and Apple TV are connected to a Linksys Velop mesh node that is 3 hops away from the network segment where the Pi is located).

4
  • 1
    Have you tried to explicitly assign the Hopper to a specific IP address?
    – Ramhound
    Oct 25, 2023 at 14:31
  • Dish Network equipment doesn't support manual configuration of its IP address. I would have to configure a static assignment in dhcpd, which I haven't yet tried.
    – David C.
    Oct 25, 2023 at 18:20
  • I was indeed suggesting you make a static assignment within DHCP.
    – Ramhound
    Oct 25, 2023 at 18:25
  • Have you tried setting the Pi's IP address to something other that 192.168.1.15? Oct 25, 2023 at 22:57

1 Answer 1

0

My first guess is that you have another DHCP server on the network, and it is offering 192.168.1.15 as a leased address. For example, it might be your router with DHCP reactivated by accident.

Stop your isc-dhcp-server temporarily, then try to run a DHCP client and see if something else offers you a lease.

As an experiment, I disabled Avahi (which seems to be what is disabling the interface), but that doesn't sound like a proper fix.

It's not disabling the interface – it's stopping mDNS operations on an interface that suddenly has had its IP address removed. Avahi does not configure or issue IP addresses, and these three syslog lines are completely irrelevant to determining the cause.

3
  • I did try that. I stopped isc-dhcp-server and then reset my computer's network interface. It fell back to a self-assigned address (in the 169.254 block) until I restarted it.
    – David C.
    Oct 25, 2023 at 18:36
  • As an experiment, I just disabled dhcpcd and configured the device's static address vi /etc/network/interfaces. So the local DHCP client won't be removing the address, but it doesn't solve the underlying problem of why the Hopper is trying to claim that address. I'll see what happens in the next few days.
    – David C.
    Oct 25, 2023 at 18:54
  • After several days, I'm seeing what I think is the same problem, but nobody was trying to claim any address outside of the configured DHCP range (which is where the Pi's .15 address is). So that part of the problem appears to be a dhcpcd bug. But I think there may still be an underlying problem (see update 2 to the original question)
    – David C.
    Oct 29, 2023 at 22:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .