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,, via the following in /etc/dhcpcd.conf:

interface eth0
static ip_address=
static routers=
static domain_name=<redacted>
static domain_name_servers=
static domain_search=<redacted>

The DHCP server is configured to serve addresses from to

subnet netmask
  option domain-name-servers;
  option domain-name "<redacted>";
  option domain-search "<redacted>";
  option routers;
  option broadcast-address;

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 to 28:57:67:3d:7a:d5 (Hopper2-br) via eth0
Oct 25 04:52:51 pi dhcpd[2993]: DHCPREQUEST for ( from 28:57:67:3d:7a:d5 (Hopper2-br) via eth0
Oct 25 04:52:51 pi dhcpd[2993]: DHCPACK on 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
Oct 25 04:52:51 pi dhcpd[2993]: DHCPREQUEST for ( from 28:57:67:3d:7a:d5 (Hopper2-br) via eth0
Oct 25 04:52:51 pi dhcpd[2993]: DHCPACK on 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 (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
Oct 25 04:53:45 pi dhcpcd[440]: eth0: hardware address 28:57:67:3d:7a:d9 claims
Oct 25 04:53:45 pi dhcpcd[440]: eth0: 10 second defence failed for
Oct 25 04:53:45 pi avahi-daemon[25338]: Withdrawing address record for on eth0.
Oct 25 04:53:45 pi avahi-daemon[25338]: Leaving mDNS multicast group on interface eth0.IPv4 with address
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
    • 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
    • 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
      • 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 (
      • 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
    • Then DHCP discover/offer/request/ack, giving it a new IP address (
    • Then 27 reuse_lease/request/ack messages (for
    • 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 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
    • 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
    • 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
  • 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).

Update 3: Last month, I disconnected my Dish satellite service and removed their equipment from the LAN. Since then, there have been no interruptions. No floods of DHCP traffic in the system log (just normal background activity) and my mesh nodes no longer lose Internet connectivity in the middle of the night (which was happening a few times a week).

I still don't know exactly what was going on, but I think it's pretty clear now that Dish's equipment was either the cause or the trigger of the problem.

I'd still love to know what happened, but at this point, I probably won't ever find out. But I'm glad the problem seems to no longer exist.

  • 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 Oct 25, 2023 at 22:57

1 Answer 1


My first guess is that you have another DHCP server on the network, and it is offering 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.

  • 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 .