我的無線網路在連線後幾分鐘到半小時或更長時間之間出現故障。
症狀:
- 新頁面打不開
- 已經在進行的下載繼續
- 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（帶有客製化Jungo's OpenRG的Hitron BVW3653板，由我的ISP提供）
世界標準時間 5 月 1 日 17:12 編輯：
$ 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 來解決（我不記得是來自有線還是無線側 - 我可以通過 ssh 訪問防火牆，我記得這是一個 ARP）問題） ，我有一個洞察力並想，“啊，這就是默認情況下禁用它的原因，它可能在該接入點固件上有錯誤，他們將其設置為零作為最後一刻的修復”，將其設置回默認，問題就消失了。
我不知道這是否是你的問題；製造商完全不同，你可能從未接觸過如此深奧的設定。
您可以嘗試的下一件事是在問題發生時運行嗅探器，以查看正在交換哪些資料包。如果您有第二台計算機，您可以將其插入路由器的乙太網路LAN 端口，並同時在其上運行嗅探器（以查看我的ARP 廣播在LAN 上可見但在無線上不可見的假設是否有一些優點） ）。
如果我的假設成立，我不知道下載將如何繼續。也許它以某種方式快取 TCP 連線狀態下的 MAC 位址？