☰

Raspberry Pi DHCP 服务器丢失其静态地址

tag-icon • tag-icon networking raspberry-pi dhcp-server avahi
Raspberry Pi DHCP 服务器丢失其静态地址

我正在使用运行 Pi-OS 10.13（内核 5.10.103-v7+）的 Raspberry Pi 3B。

我正在运行bind9为我的 LAN 提供 DNS 服务，并isc-dhcp-server为我的 LAN 提供 DHCP 服务。

Pi 通过以下方式配置静态 IP 地址 192.168.1.15 /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>

DHCP 服务器配置为提供从 192.168.1.32 到 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;
}

多年来，Pi 一直以这种配置和能力出色地工作。然而，最近，我早上醒来时会发现它处于离线状态（连带我的 LAN 也瘫痪了）。查看系统日志，似乎另一个设备（我的 Dish Network Hopper 卫星接收器）正在声明其 IP 地址，然后 Pi 和dhcpd进程avahi-daemon放弃了其地址，尽管它是静态配置的。

从中/var/log/syslog，我看到了故障发生时的情况：

Hopper（以及其他 Dish Network 设备）似乎都在更新租约，并获得与以往相同的地址：

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

然后是大量reuse_lease信息。以下信息在同一秒内出现了 100 次：

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

然后我看到一堆来自 Pi 的 MAC 地址的路由器广告，用于其自己的 IPv6 地址。该消息的 10 份副本：

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!

然后，令人费解的是，Hopper 似乎试图声明 192.168.1.15（Pi 的以太网地址），导致 Pi 放弃其地址并因此离线：

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.

此问题间歇性发生。我可以在问题发生前 1 到 7 天的任何时间去。当问题发生时，总是在清晨（凌晨 4:00 到 5:00 之间）。

这到底是怎么回事？我该如何解决这个问题？如果 Hopper 的固件有问题（很可能是这样），有什么方法可以阻止它产生这些问题吗？

作为一项实验，我禁用了 Avahi（这似乎是禁用界面的原因），但这听起来不像是一个正确的修复。

我最初将 DHCP 租约时间设置为 24 小时（默认）和 30 天（最大）。为了防止这会导致表溢出，我将它们更改为 12 小时（默认）和 24 小时（最大），看看这是否有帮助。

更新：我刚刚遇到本文，它报告了两年前的类似症状。这让我怀疑这是否只是 中的一个错误dhcpcd。作为测试，我正在重新配置 Pi 以禁用其 DHCP 客户端，而是通过 获取其静态地址/etc/network/interfaces。

更新 2：几天后，在 Pi 配置为真实静态地址（而不是静态dhcpcd配置）后，我注意到网络上的新节点在大约与之前相同的时间（从 4:45 到 4:50）发出了同样的 DHCP 消息洪流。但由于没有本地 DHCP 客户端来删除我的本地地址，因此该设备能够渡过洪流。抱歉这里的数据转储，但我不确定我看到的是正常情况还是表明存在问题。

  • DHCP 发现/提供/请求/确认来自 Joey-MoCA (...:69) - DISH Network STB，通过 MoCA 连接到 Hopper，将其桥接到家庭 LAN。获取地址 192.168.1.32
    • 这看起来非常正常，我认为它不代表存在问题。但由于它与数据包泛滥几乎同时发生，所以我在这里提到它。
  • Hopper 的 DHCP 通信序列
    • DHCP 从 Hopper 的以太网端口发现/提供/请求/确认，获取地址 192.168.1.247
    • 从 Hopper 的 Wi-Fi 接口（我猜是通过其内部桥接器，因为它实际上并未连接到我的 Wi-Fi）发现/提供/请求/确认 DHCP，获取地址 192.168.1.185
      • 这看起来像是 Hopper 固件中的一个错误。 但由于它的 Wi-Fi 尚未配置且报告已关闭，我不确定我是否可以采取任何措施。
    • 然后从 Hopper 的桥接接口（与以太网接口相同的 MAC - 我只能区分它，因为它宣传的是不同的名称）进行另一个 DHCP 发现/提供/请求/确认，获得相同的地址（192.168.1.247）。
      • 这看起来像是 Hopper 固件中的另一个错误。如果 Hopper 尝试桥接其所有网络接口，则接口不应该请求不同的地址 - 桥接器应该有一个地址，而没有其他地址。
    • 然后是大量 DHCP repeat_lease/discover/offer/reuse_lease/request/ack 消息。同一秒内出现了 19 个该序列实例，全部来自 Hopper，获取其地址。
  • 然后，我看到房间里另一台设备（Apple TV）发来的一系列消息，该设备似乎拒绝了提供给它的几个 IP 地址，最后才确定了一个：
    • 它发出两条 DHCP 拒绝消息，放弃地址 192.168.1.246。
    • 然后 DHCP 发现/提供/请求/确认，并为其提供一个新的 IP 地址 (191.168.1.239)。
    • 然后是 27 条 repeat_lease/request/ack 消息（针对 192.168.1.246）
    • 然后，该 Apple TV 针对同一 IP 地址发出 243 条 DHCP 拒绝/请求消息
  • 然后再次从 Joey 发现/提供 DHCP，针对相同的 192.168.1.32 地址
  • 然后是来自 Apple TV 的更多流量（我猜是之前洪流的一部分）：
    • DHCP 发现/提供/请求/确认该 Apple TV。这次的地址是 192.168.1.240
    • 然后，又有 8 条针对 .240 地址的 repeat_lease/request/ack 消息涌入
    • 随后 DHCP 拒绝该地址
    • 然后从中发现/提供/请求/确认，这次获取 192.168.1.241
    • 然后使用该地址发送 9 条 repeat_lease/request/ack 消息
    • 然后 3 次 DHCP 拒绝该地址
    • 然后是发现/提供/请求/确认序列，获取 192.168.1.229。
  • 这样数据包洪流终于结束了。此后的日志看起来正常，没有任何大量相同消息的洪流？

这是 DHCP 服务器总是要处理的问题吗？可能是我安装时出现了错误isc-dhcpd？配置时出现了错误？还是它对我 LAN 上其他设备（显然是我的 Hopper 和其中一台 Apple TV）中的错误做出了正确响应？或者可能是对 LAN 问题的反应（Hopper 和 Apple TV 连接到 Linksys Velop 网状节点，该节点距离 Pi 所在的网络段有 3 跳）。

更新 3： 上个月，我断开了 Dish 卫星服务，并从 LAN 中移除了他们的设备。从那时起，就再也没有中断过。系统日志中没有大量 DHCP 流量（只是正常的后台活动），我的网格节点也不再在半夜失去互联网连接（这种情况每周都会发生几次）。

我仍然不知道到底发生了什么，但我认为现在很清楚，Dish 的设备是问题的根源或诱因。

我仍然想知道发生了什么，但目前我可能永远也找不到答案了。不过我很高兴这个问题似乎不再存在了。

答案1

我的第一个猜测是你有其他网络上的 DHCP 服务器，它提供 192.168.1.15 作为租用地址。例如，它可能是您的路由器意外重新激活了 DHCP。

暂时停止您的 isc-dhcp-server，然后尝试运行 DHCP 客户端，看看是否有其他东西为您提供租约。

作为一项实验，我禁用了 Avahi（这似乎是禁用界面的原因），但这听起来不像是一个正确的修复。

这不是禁用界面——而是停止 mDNS 操作在 IP 地址突然被删除的接口上。​​Avahi 不会配置或发布 IP 地址，并且这三个系统日志行与确定原因完全无关。

相关内容