ルーターを買い換えたらCloudready搭載機がWiFiにつながらなくなった話
事件が起こるまで
先日、テレワーク中に回線速度が出なくなる現象に遭遇しました。
もろもろ調べてみたところ、おそらくルーターが古いことでIPv4 over IPv6が使えず、IPv4のフレッツ網の出口でどん詰まりになったのが原因じゃないか？となりました。
旧ルーターはすでに５年近く経過しており、IPoE対応など、動きは問題ないですがIPv4 over IPv6に対応していなく、また、ファームウェアなどの面で限界を迎えてきておりました。
そんなわけで、コスパ含めいろいろ調べた結果、Aterm WG1200HP4(NECプラットフォームズ製)を購入するに至りました。
設定そのものは順調に完了し、IPoEはもとより、IPv4 over IPv6がついに我が家にも導入されることになりました。
そして、メインマシン他、スマホ類も問題なく接続が完了していました。
事件は突然起こった
そんな中、Cloudreadyをインストールしていた１機のみが急にWiFiにつながらなくなりました。
2.4GHzのみの環境ですので、最初は端末側の設定の問題かなーﾊｯﾊｯﾊｰ
と高を括っていたのですが・・・、何度リトライをしてもつながらず、「これはやばいやつでは・・・」となり、まじめに調べることに。
そもそもCloudreadyとは
CloudreadyはChromebookみたいなものと覚えておけば大丈夫です。（おい
簡単にいうと、ほぼChromebookのOSを家庭用であれば無料でインストールして使えるという代物です。
スペックが低いPCでも割ときびきび動いてくれるのが特徴です。
今回のPCもIntel Atom Z3735F/2GBメモリ/eMMC 32GB/WiFi 802.11bgnという構成です。
↓参考
WG1200HP4で行った対策
WG1200HP4の設定画面ですが、こんな感じです。
Wi-Fi 自動設定動作モード（自動→5GHz）、Wi-Fi 自動設定（らくらく無線/WPS 自動→らくらく無線）に変更しました。
Cloudreadyの接続条件として、WPSが有効だとだめらしい。
で、デフォルトから変更した箇所としては、オートチャンネルセレクト機能（ON→OFF）、TVモード（ON->OFF）です。
そして、設定し、再起動しました。
これでいけるのでは・・・！
それでもつながらない
が、つながらず・・・。
他に設定項目があるのか・・・？となり再度設定画面を確認してみる。
「詳細な項目を表示」・・・？→設定まで
「詳細な項目を表示」・・・？ポチっとしてみる。
！！ なんかでた！
無線暗号化強化（PMF）、A-MSDUってなんだ・・・？
デフォルトはどちらもONのところ、両方OFFにして再起動。
・・・上手くいった！
いろいろ繰り返した結果、上記画像の通りの設定になりました。
無線暗号化強化（PMF）とは
https://en.wikipedia.org/wiki/IEEE_802.11w-2009
802.11wで策定されたもので、Protected management framesというらしい。
https://www.wlan-business.org/archives/19812#:~:text=Protected%20Management%20Frames%20(PMF)%20%E2%80%93%20802.11w,-WPA3%E3%81%A8Enhanced&text=PMF%E3%81%A7%E3%81%AF%E4%B8%BB%E3%81%AB%E3%81%AF,%E6%A9%9F%E8%83%BD%E3%82%92%E6%8F%90%E4%BE%9B%E3%81%97%E3%81%BE%E3%81%99%E3%80%82&text=%E7%8F%BE%E7%8A%B6%E3%81%AE%E6%9A%97%E5%8F%B7%E5%8C%96%E3%81%AA%E3%81%97,%E5%AE%B9%E6%98%93%E3%81%AB%E5%AE%9F%E8%A1%8C%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%99%E3%80%82
WPA3とEnhanced OpenでPMFによる管理フレームの保護機能が必須項目として扱われています。PMFでは主には管理フレームの暗号化やなりすましの攻撃からの防御機能を提供します。De-authentication frameやDisassociation frame等の管理フレームも防御の対象です。アクセスポイントは802.11のビーコンやプローブでOWE対応と共にPMFの利用を示す情報をアドバタイズしています。
ということで、暗号化に関する機能の模様。
これが原因っぽい。
A-MSDUとは
これまでの無線LANでは、無線フレームと、Ethernetフレームが一対一に対応していた。この関係を変え、複数のEthernetフレームを1つの802.11フレームへとまとめて送信するのが「フレームアグリゲーション」である。これは、多数の細かなパケットを1つのフレームへまとめることで、送信待ち時間やACK待ち時間を減らそうという仕組みである。これには2つの方法があり、両者を併用することもできる（図1）。
つは、複数のEthernetフレームの中からMACヘッダ以降のデータを最大8KBまで連結し、単一の無線フレームへ束ねる方法である。このフレームを「A-MSDU（Aggregation-MAC Service Data Unit）」と呼ぶ。
A-MSDUには、802.11のプリアンブルや変調方式を指定するヘッダを含む無線ヘッダと、MACヘッダが各1つずつある。このため、通信の待ち時間などによるオーバーヘッドは少なくなる。しかし、誤り検出のためのFCS（Frame Check Sequence）も1つしかないため、エラーが生じればA-MSDU全体を再転送するしかない。また、A-MSDUは従来と同じ方法のACKで受信応答され、後述するブロックACKは使えない。
もう1つの方法は、複数のEthernetフレームの中からMACヘッダとデータを含むMACフレーム作成し、64KBを上限に連結して送信するものだ。これを「A-MPDU（Aggregation-MAC Protocol Data Unit）」という。
A-MPDUには無線ヘッダが1つだけだが、MACヘッダとFCSは個々のMACフレームごとにある。このため、A-MSDUよりオーバーヘッドが増えるが、エラー発生時にはエラーとなったフレーム部分の再送信だけで済む（ブロックACKを使う）。なお、A-MSDUにMACヘッダを付けたものを連結して、A-MPDUとして使うこともできる。
加えて、オーバーヘッドの原因となるACKにも工夫がされている。それが「ブロックACK」だ。最大64KBの無線フレームに対して、一括して1回のACKで応答する。受信端末側の受信ステータスを示すビットマップを持つため、特定のフレームについて成否（エラーの有無）を通知することができる。
これらの仕組みのおかげで、待ち時間を大幅に減らすことが可能になった。理論上のスループットは約500Mbpsとなり、11nの規定値である600Mbpsに対して約80％程度を実現できることになる。
なるほど、わからんｗ
MTUあげて効率を上げるようなものか（しらんけどｗ
結論
最終的には、Cloudready（Chromebookも？）でつながらなくなった際は以下の点を見直すとつながるようになるかもしれません。
・WPSの無効化
・QoSの無効化
・PMF（MFPと書いてある場合もあるとか）の無効化
追記：リリースノートを見た結果
Cloudreadyの最新版のRelease Noteを見たのですが、
Fix for WiFi PMF mode connection issue: Some devices, like HP 250 G7, were unable to connect to WiFi access points that used PMF (802.11w) mode. The issue is now resolved.
ってかいてあるのに、今回の端末ではどうやら対策できていなかった模様・・・。
この記事が気に入ったらサポートをしてみませんか？