接続後数分から 30 分以上経つと、ワイヤレスが機能しなくなります。
症状:
- 新しいページが開かない
- すでに進行中のダウンロードは続行されます
- 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 (ISP から提供された、カスタマイズされた Jungo の OpenRG を搭載した Hitron BVW3653 ボード)
編集 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 によってロックされているため、ルーター上の Web ページにのみアクセスできます。
答え1
この答えはすべて推測になります。これが実際に原因であるかどうかはわかりませんが...
ルーターを ARP テーブルから削除すると、コンピューターは次にルーターにパケットを送信するときに ARP パケットを送信するよう強制されます。投稿した例ではコンピューターの ARP テーブルは正常であるように見えるため (「修正」の前後で同じ)、この ARP パケットによってルーターの ARP テーブル内の壊れた部分が修正されると推測できます。
ルーターの ARP テーブルを確認できたとしたら、コンピューターの MAC アドレスの代わりに「(不完全)」と表示されるのではないかと思います (どのように表示されるかを確認するには、存在しない LAN アドレスに ping を実行してみてください)。ARP エントリの有効期限が切れ、ARP パケットがブロードキャストされ、そのブロードキャスト パケットがコンピューターに届かなかった場合 (または応答パケットがルーターに届かなかった場合)、この状態になります。ARP パケットによってエントリが完成し、コンピューターに IPv4 パケットを再度送信できるようになります。
では、なぜこのようなことが起こるのでしょうか? 考えられる原因は 2 つあります。ルーターまたはコンピューターのファイアウォールの設定が間違っている (可能性は低いと思います)、またはワイヤレス ルーターからのブロードキャストに問題がある可能性があります。
802.11 標準のブロードキャスト パケットには多少問題があります。ブロードキャスト パケットは関連するすべてのステーションに送信されるので、
- これらは確認応答されないため、AP は受信されたかどうかを知ることができません。つまり、1 回の誤った静的バーストによってブロードキャスト パケットが破棄される可能性があります。
- これらは、すべてのステーションが受信できる速度で送信する必要があります。AP は、レート制御アルゴリズムによって検出された最適なレートを使用することはできません。これは通常、BSS の基本レートよりも大幅に低いレートを意味します。これにより、通信時間は長くなりますが、前述の問題の解決に役立ちます (通常、レートが低いほど、多少堅牢になります)。
- 同じパケットは関連するすべてのステーションでデコードできる必要があるため、ステーションの個別のキーで暗号化することはできません。代わりに、関連するすべてのステーションが知っている別のグループ キーで暗号化する必要があります。このグループ キーは定期的にローテーションされます (そうしないと、ネットワークから離れたステーションがブロードキャスト パケットを引き続きデコードできます)。
個人的に、この最後の点に関連する不可解な障害に遭遇したことがあります。以前構成したアクセス ポイントでは、グループ キー間隔が無効になっていました。「これは馬鹿げている」と思い、「なぜそのセキュリティ機能を無効にしているのだろう」と考え、1 時間に設定しました。正しい側から ping することで解決できる断続的なワイヤレス接続の問題をしばらく修正した後 (有線側からだったか、ワイヤレス側からだったかはもう覚えていません。ファイアウォールに ssh アクセスでき、ARP の問題だったと記憶しています)、「ああ、これがデフォルトで無効になっている理由だ。おそらくそのアクセス ポイントのファームウェアにバグがあり、土壇場での修正として 0 に設定されたのだろう」と思い、デフォルトに戻したところ、問題は解消しました。
それがあなたの問題かどうかはわかりません。製造元はまったく異なりますし、おそらくそのような難解な設定に触れたことがないのでしょう。
次に試すことができるのは、問題が発生したときにスニファーを実行して、どのパケットが交換されているかを確認することです。2 台目のコンピューターがある場合は、ルーターのイーサネット LAN ポートに接続し、同時にそのコンピューターでもスニファーを実行できます (ARP ブロードキャストが LAN 上では表示されるがワイヤレスでは表示されないという私の仮説に根拠があるかどうかを確認するため)。
私の仮説が正しい場合、ダウンロードがどのようにして継続されるのか全く分かりません。おそらく、TCP 接続状態で MAC アドレスを何らかの方法でキャッシュしているのでしょうか?