我的无线网络在连接几分钟到半小时或更长时间后就会出现故障。
症状：
- 新页面无法打开
- 正在进行的下载继续
- ping 8.8.8.8 不工作
“修复”很简单（持续随机时间）：
$ sudo arp -d 192.168.1.1
这个解决方案没有任何意义，因为我已经检查过，它不是 ARP 毒药。
对于为什么会发生这种情况有什么想法吗？
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms
$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=55.2 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=47 time=53.4 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 53.425/54.358/55.282/0.923 ms
无线路由器：ZonHub 1.0（Hitron BVW3653 主板，带有定制的 Jungo 的 OpenRG，由我的 ISP 提供）
编辑于 5 月 1 日，17:12 UTC：
$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
inet6 fe80::21c:bfff:fe2a:9b6/64 scope link
valid_lft forever preferred_lft forever
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 7999ms
$ sudo arp -an
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0
$ sudo arp -d 192.168.1.1
$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=53.5 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=53.8 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=47 time=79.8 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 53.544/62.396/79.815/12.317 ms
$ ip addr show wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:1c:bf:2a:09:b6 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global wlan0
inet6 fe80::21c:bfff:fe2a:9b6/64 scope link
valid_lft forever preferred_lft forever
$ sudo arp -an
? (192.168.1.1) at 00:05:ca:69:96:58 [ether] on wlan0
正如我所说，不是 ARP 毒药。
注1：我只能通过路由器访问网页，其他所有内容都被 ISP 锁定了。
答案1
这个答案完全是猜测，我不知道这是否真的是原因，但是......
当您从 ARP 表中删除路由器时，您的计算机在下次想要向路由器发送任何数据包时，都会被迫发送一个 ARP 数据包。我猜这个 ARP 数据包修复了路由器 ARP 表中出现的所有问题，因为在您发布的示例中，您的计算机的 ARP 表似乎没有问题（“修复”之前和之后都一样）。
我猜想路由器的 ARP 表（如果您能查看的话）会显示“（不完整）”而不是您的计算机的 MAC 地址（尝试 ping 一个不存在的 LAN 地址，以查看其样子）。如果其中的 ARP 条目已过期，它会广播 ARP 数据包，并且该广播数据包从未到达您的计算机（或响应数据包从未到达路由器），则会出现该状态。您的 ARP 数据包完成条目，它可以再次向您的计算机发送 IPv4 数据包。
那么，为什么会发生这种情况呢？我能想到两个可能的原因。路由器或计算机上的防火墙配置错误（我认为这不太可能），或者无线路由器的广播存在问题。
802.11 标准中的广播数据包有些问题。由于它们被定向到所有相关站点：
- 由于它们没有被确认，因此 AP 无法知道它们是否被接收。这意味着一次错误的静态突发可以杀死广播数据包。
- 它们必须以所有站点都能听到的速率发送。AP 不能使用其速率控制算法找到的最佳速率。这通常意味着比 BSS 的基本速率低得多的速率。这会占用更多空中时间，但有助于解决上一个问题（较低的速率通常更稳健一些）。
- 由于所有相关站点都应能解码同一个数据包，因此不能使用站点的单独密钥对数据包进行加密。相反，必须使用所有相关站点都知道的单独组密钥对数据包进行加密。此组密钥会定期轮换（否则离开网络的站点仍可解码广播数据包）。
我个人似乎遇到过与最后一点相关的神秘故障。我曾经配置过一个接入点，其中禁用了组密钥间隔。“这太愚蠢了”，我想，“他们为什么要禁用该安全功能？”，然后将其设置为一小时。经过一段时间修复间歇性无线连接问题，这些问题可以通过从正确的一侧 ping 来解决（我不记得是从有线一侧还是无线一侧 ping 了——我可以通过 ssh 访问防火墙，我记得这是一个 ARP 问题），我突然想到，“啊，这就是它默认禁用的原因，可能是该接入点固件存在错误，他们将其设置为零作为最后一刻的修复”，将其恢复为默认值，问题就消失了。
我不知道这是否是你的问题；制造商完全不同，而且你可能从未接触过如此深奥的设置。
您可以尝试的下一件事是在问题发生时运行嗅探器，以查看正在交换哪些数据包。如果您有第二台计算机，您可以将其插入路由器的以太网 LAN 端口，并同时在该端口上运行嗅探器（以查看我的假设（即 ARP 广播在 LAN 上可见但在无线网络上不可见）是否有道理）。
我不知道如果我的假设成立，下载将如何继续。也许它会以某种方式在 TCP 连接状态下缓存 MAC 地址？