一般的な使い方をしている人には余り関係ないと思いますが、使用してみて予想外だったのはルーター機能が物足りません。

細かいポートの制御などは今まで使用していたSynology rt2600acの方がかなり優秀でした。

ASUSさんはたくさんの機種を販売してるのでソフトウェアの作り込みも期待していただけに、これは残念でした。

その為、ルーターは以前のSynology rt2600acを引き続き使用。

ASUS RT-AX88Uは無線アクセスポイントモードで使うことにしました。
　※アクセスポイントモードでもメッシュが使えるのが優秀！

Synologyが非常に細かくいろんな事を設定できるのに慣れていたからか、設定項目が少なすぎて戸惑います。

また、私にとって致命的な不具合がありました。問い合わせしましたが中国人担当者の再現しないの一点張り。

私にとって致命的なのがルーターの設定画面のAi Protection（ペアレンタルコントロール）。
ここの画面上には
・クライアントごとに【インターネットを使用することができる時間を制限することができる】

・【インターネットアクセスを「許可する時間帯」と「禁止する時間帯」】
と記載されています。

ペアレンタルコントロールのOFFの時間は正常にWiFiにリンクアップできます。
しかし、ペアレンタルコントロールのONの時間にWiFiに新規にリンクアップしようとすると、次の画像になり、リンクアップが弾かれます。
すなわちWANの外側に出れないのではなくWi-Fiにリンクアップできないという症状になるのです。その為、宅内のNASに接続することもできません。

たとえばAM9:00～15:00にiphoneがインターネットアクセスを禁止する時間帯と設定します。
この状態でiphoneを持って外に昼食に出ます。その後、13時に帰宅します。すると、上記の画像になり、リンクアップがはじかれます。
リンクアップが弾かれるので、宅内のNASに繋がりません。
宅内のNASは「インターネット」じゃないですよね？

正しい動作は、ペアレンタルコントロールの時間設定はオンの時間帯は、「WANから先のインターネットアクセス」が制限されるという挙動ならば良いのです。

ただし、現状の挙動は、ペアレンタルコントロールの時間設定はオンの時間帯は、「WiFiのリンクアップが弾かれてしまうので、宅内のNASとかにも繋がらない」という挙動になっています。
　※ずっとWi-Fiが繋がる家の中に居れば、リンクアップしたままなのでインターネットの世界には繋がらず、宅内LANには繋がるという状態になります。

この挙動はマニュアルに記載されている
【インターネットアクセスを「許可する時間帯」と「禁止する時間帯」】
ではないです。

宅内LANはインターネットではないです。

Wifiがリンクアップしなくて、宅内LANが使えないのは、記載してる事と違うと言っても中国人担当者には理解されない模様。

上記の機能が致命的でした。子供もコロナで自宅に居ることが多く、本来学校の時間帯は制限をしたいと思いましたがそれすらままならない。。。

残念でした。

無線の電波の強さ、スピードは文句なしです。
この点においては非常に良いです。メッシュもしてるから家中のどこでも快適に繋がります。

リンク速度も高速。2.4Gbpsで安定して繋がってます。もはや有線LANよりも速いのです

ただし、残念な点があります。

無線アクセスポイントモードにすると「リンクアグリケーション」、「ゲーミングアクセラレーター」機能は無効になります。
せめて「リンクアグリケーション」はアクセスポイントモードでも動いて欲しかったなぁ。。。

※ファームウェアアップデートでアクセスポイントモードでも「リンクアグリケーション」が動くようになりました。

なお、RT-AX88UはWANポート1個、LANポート8個の合計9ポートあります！

最近のWi-Fiの機能の一つでメッシュというのがあります。

中継に似てるのですが、大きく異なります。

メッシュは何が良いかって子機が親機の分身であるという点。ですので、SSIDも共通です。

中継だと最初のWi-Fiを掴んだら、その電波が途切れるまで掴んだままで電波が途切れたら最寄りの一番強い電波を掴みなおす。
その為、Wi-Fiが弱くなって一瞬切れて切り替わるという挙動です。

それに対して、メッシュだとシームレスに強い電波に切り替わるのがメリットですね～。

なお、メッシュには親機コントローラー ⇔ 子機エージェント間のバックホール接続を「有線LANで行うタイプ」と「無線で行うタイプ」の２種類があります。

　※TP-Linkの「OneMesh」などメーカーによっては有線バックホール接続が不可のメッシュもある。

可能であれば親機⇔子機間のバックホール接続は有線LANの方が良いですね。

有線LANをバックホールにするとコントローラとエージェントのWi-Fiエリアが重なっていなくても構わなくなります。
電波の届かない離れた部屋間でも有線LANケーブルで接続されてさえいえば移動後の再接続がスムーズに行われるようになりますので、非常に快適になります。

僕は公式に記載のアクセスポイントモードでの有線LANバックホール接続にてMeshを構築しました。

設定不要で動いてしまうのが非常に簡単です。

なお、メッシュ機能はルーターモードでも、アクセスポイントモードでも動くので柔軟ですね

ただ、メッシュを有効にしてしまうと、子機は一切の設定ができなくなります。
　※2020/12/08のファームウェアアップデートで変更されました。

できることは親機の画面から、

　・子機に接続されている機器台数の確認

　・子機のファームウェアバージョン、およびファームウェアアップデート

のみです。

子機のIPアドレスをWebブラウザでアクセスしても親機に転送されます。
再起動もできません。

再起動くらいWebからやりたかったなぁ。いちいち本体の電源ボタン押すの面倒だもん。。。

それにしても、メッシュはホントいいですよ！マジでオススメ！

我が家は下記の間取り図で、67平米なので正直なところ１台でもなんとか届くのですが、メッシュはどこでも安定して常に電波MAX！

実際に設置した場所は

・メッシュの親機が利用頻度の高いリビングのTVの上

・子機は洋室（１）のクローゼットの中
　　※このクローゼット内の壁から1Fマンション管理室からのインターネット回線がきて、Synologyのルーターに繋がっている。

洋室（１）のクローゼットの中にあるのでルーフバルコニーに出ても電波を安定して掴みます。

ASUSのネットワーク機器はアクセスポイントとして使用するならばアリというのが僕の中での結論です。

ただ、普通の人はあまりルーターの細かいところは求めないでしょうからね。
設定が何もしなくて高速、簡単なASUSは使いやすいと思います。

なので、普通の人はASUSは買いです！

逆に細かなルーター機能も求めるならば他社買った方が幸せになれるかもと思います。

そういった感じなので、普通の一般人には非常にオススメできる製品です。

なお、現在の我が家は

●ルーター：Synology rt2600ac（無線機能はOFF） 

●無線アクセスポイント：ASUS RT-AX88U × ２台（メッシュ）

という構成で落ち着きました。

2025/8/15のファームウェアが出た際に、多くのセキュリティ修正が入りました。

そして、「重要：このファームウェアをインストールした後、すべての新しいセキュリティ調整を有効にするため、工場出荷時設定へのリセットを強く推奨します。」とのこと。

■ASUSルーター8000台がボットネット「AyySSHush」に感染 ～ファームウェア更新でも消えないSSHバックドアの驚異

過去にこんなことがあったから、セキュリティ更新＆初期化で一掃したいという思いがあるのかな？

正直、アクセスポイントモードだし、メッシュも組んでるので面倒くさかったけど初期化しました。

手順

①２台のファームウェアをアップデート。
②メイン機にログインして、ノード機を削除（初期値に戻る）。
③ノード機の初期IPの192.168.50.1にアクセス。Wi-Fi経由でも良い。
　適当に初期設定を行い、初期値IP以外を割り当てる。
④メイン機を工場出荷時状態に初期化。
⑤メイン機の初期IPの192.168.50.1にアクセス。初期設定を行う。
　・イーサネットバックホールを有効
　・ジャンボフレームを有効
⑥ノード機を工場出荷時状態に初期化。
⑦ノード機の初期IPの192.168.50.1にアクセスしてモードをMesh子機モードに変更。
⑧メイン機からノード子機を探して追加する。
⑨メイン機からノード子機設定のジャンボフレームを有効化する。

なお、当機器だけでなく他のASUS機でも同様のファームが出ています。

当方の所持してる、Wi-Fi7機器のRT-BE92Uにもファームウェアアップデートが来ておりました。

2022年8月より2018年に発売されたRT-AX88Uを対象とするβ版ファームウェアのVer.9.0.0.4.388_20477の配信が開始されました！

なんと、このβ版ファームウェアで「ASUSWRT 2022」と呼称されるアップデートによりWireGuardが利用可能になった他、ゲーミングルーター以外の製品では初めてVPN Fusionにも対応しています。

VPNフュージョンの設定方法 | サポート 公式 | ASUS 日本

●ASUS RT-AX88U ファームウェアバージョン 9.0.0.4.388.20477

1. WireGuard VPNサーバーおよびクライアントに対応。
2. VPNフュージョンをサポート。スマートテレビ、ゲーム機などのネットワーク機器に、VPNクライアントソフトをインストールすることなく、簡単にVPN接続を実現できます。
3. VPNフュージョンでHMA VPNをサポートし、190以上の国のストリーミングサイトに安全かつ迅速にアクセスすることができます。
4. 新しいデバイスの接続通知をサポート。
5. ASUSルーターアプリでの接続診断に対応。
6. インスタントガード2.0に対応し、家族や友人を簡単にVPN接続に招待することができます。
7. 7.ペアレンタルコントロールのバージョンアップと報酬の追加、柔軟な設定が可能な新スケジューラーを搭載。

なにげに素晴らしいアップデート！

ただ、僕はアクセスポイントモードで使ってるから恩恵受けれないんだけどねぇ・・・

友人のマンション回線が「UCOM光レジデンス」でして人数も多くちょっと遅い。

そこで有料オプションのConnectix（コネクティクス）を契約すると20台までの割り当てられたIPだけが速くなるという事なのです。
多段ルーターを避けるためにアクセスポイントモードで使用していたのですが、20台を超えちゃうので、仕方なくアクセスポイントモードではなくルーターモードで動かすことにしました。

その際にルーターの推奨接続台数って、どういう計算なんだろう？って友人と話題になり気になったのです。

一般的なルーターの同時接続可能台数は、理論上253台。
とはいえ、接続台数が増えるほどルーターに負荷がかかりますので、各メーカーが推奨接続台数を記載していることがほとんどです。

言い換えればコレはメーカー側の安定動作するための保証台数って位置づけなのかなと思ってます。

僕の使ってるASUS RT-AX88Uが21台。
それの少し廉価版のASUS RT-AX86Uだと70台。
CPUもメモリも同じ。OSも同じバージョン型番。アンテナが違うくらい。
同じようなスペックなのになんで差が出るの？
接続台数の基準が2018年は厳しめだったけど2020年の頃は緩められた？

そうとしか考えられないけど、どういう基準なんだろう？

●機種：ASUS RT-AX88U

発売日：2018年12月21日

CPU：BCM 4908 1.8GHz クアッドコア
メインメモリ：1GB

LAN/WAN：1GbEのみ
推奨接続台数：21台

●機種：ASUS RT-AX86U ※Proじゃない無印

発売日：2020年 9月11日

CPU：BCM 4908 1.8GHz クアッドコア
メインメモリ：1GB

LAN/WAN：2.5GbE×1あり
推奨接続台数：70台

2023年のCPUやメモリの同じ機種でも比較してみた。
ゲーミングモデルのTUF-AX6000が70台。
縦置き小型のRT-AX59Uが64台。
この2つはメモリもCPUも発売時期もほとんど同じでアンテナ性能が違うくらい。

たいした差では無いことがわかります。

やはり2018年は厳しめだったけど2020年以降で基準が緩んだのかな？

●機種：ASUS TUF-AX6000 ※ゲーミングモデル

発売日：2023年4月14日

CPU：MediaTek MT7986A 2.0GHz クアッドコア
メインメモリ：512MB

LAN/WAN：2.5GbE×2あり
推奨接続台数：70台

●機種：ASUS RT-AX59U ※縦置きのアンテナ内蔵小型モデル

発売日：2023年 8月25日

CPU：MediaTek MT7986A 2.0GHz クアッドコア
メインメモリ：512MB

LAN/WAN：1GbEのみ

推奨接続台数：64台

2024/4/29 追記

同じようなスペックなのになんで差が出るのかな？ということでASUSに問い合わせてみました。

＝＝＝＝＝＝
いつもお世話になっております。
ASUSサービスセンターでございます。
お忙しいところご連絡いただきまして、誠にありがとうございます。

推奨接続台数に関しては製品に搭載されているCPUやメモリ、WiFiチップ等により算出しています。
詳細な算出方法は申し訳ございませんがお答えできかねます。

RT-AX88U発売当初はWiFi6自体もドラフトの状態でしたので、弊社としても十分な情報が無くWiFi5の基準で算出しております。
実際はRT-AX88Uも現在の算出方法で出しますと、ご指摘の通りRT-AX86Uと同等の推奨接続台数となります。

ご理解いただけますと幸いです。

以上、お手数をお掛けし大変申し訳ございませんが、宜しくお願い致します。
その他ご不明点等がございましたら、お気軽にお問い合わせください。

ASUSサポートセンター

担当者：Liu
＝＝＝＝＝＝
とのこと。

製品発売時はWi-Fi6がドラフトだったから、Wi-Fi5で検証していたので21台だけど、ちゃんとWi-Fi6で検証したら70台なのか！

ちゃんと答えてくれたのはありがたいが、Webページも修正して欲しいよなぁ

早まって後継機種を２台買っちゃったよ。

高速な設定にするためには、8chをまとめる160MHzモードにする必要があります。

そうすると、どうしてもDFS干渉するチャンネルと使わざるを得ません。

これは仕方の無いことです。

DFS干渉が嫌ならば、36,40,44,48の4chをまとめて80MHzモードで使うしかない。

■ASUSルーター DFSの影響回避設定

しかし、80MHzモードだと1201Mbpsでしかリンクアップしません。

160MHzモードなら2402Mbpsでリンクアップします。

なので、当方は2402Mbpsでリンクアップをさせたいと思って160MHzモード有効で使ってます。

そして設定は36～64を割り当てたいと思ったので、メインのチャンネルと36chを指定。

こちらの日記にも書きましたが、ある日に確認すると1201Mbpsでリンクアップしていました。

ログを見ると「Radar detected」の文字があり、いったんチャンネル移動。

その30分後に元のチャンネルに戻ると思ったら戻って無くて80MHzモードだったので1201Mbpsでしかリンクアップしなかったという状況です。

よくよく調べてみると、ASUSのWebサイトにDFSの挙動について書いてありました。

Q2. ルーターのDFSチャンネル（例:108ch）が有効に設定されており、ルーターがレーダー信号を検知して他のチャンネル（例:44ch）に切り替え場合、レーダー信号がなくなった後ルーターは自動的にDFSチャンネル（例;108ch）に戻りますか？

A2. 動作は設定により異なります。

(1) チャンネルを［自動］（既定値）に設定している場合、同一チャンネルが他のデバイスで使用されていない場合、ルーターは自動的に元のチャンネルに戻ろうとします。

(2) チャンネルを特定のチャンネルに設定している場合、デバイスとの接続断を回避するため、ルーターは積極的に元のチャンネルに戻ろうとすることはありません。

36ch指定じゃなくて自動にすれば160MHz帯に戻ると言うことか！

ということで検証。

チャンネル割り当てを自動に変更した後に、DFS干渉を受けても、しばらくするとちゃんと160MHz有効で戻ることを確認しました！

これって、Webのよくある質問に記載じゃなくて、マニュアル記載で良いと思うんだけどなぁ。

なお、ASUSサポートセンターにDFSレーダー検知について質問しました。

DFSレーダー検知は全てのメッシュAPで検出するそうです。
その場合はレーダーを検出したAPから他のAPに通知され、同時にレーダーに該当するチャンネルから他のチャンネルに切り替える挙動になっているそうです。

ASUSサポートは優秀だなぁ。

システムログの中で「Radar detected」という文字がレーダーを受信したというログです。

その後、switching to channel spec: 0xxxxx (100/160) というのが表示されます。

上記の場合、100chの帯域幅160MHzに切り替わりました。という内容になります。

2024/8/13 チャンネルを36ch固定から自動に変更。

自動で割り当てされたチャンネルが56、160MHz有効、2402Mbpsでリンクアップを確認。

2024/8/15　レーダーを受信してチャンネルが100に変わっていた。

自動で割り当てされたチャンネルが100、160MHz有効、2402Mbpsでリンクアップを確認。

と言うことで当方の使い方的なスペックを求める場合は、

・「チャンネル」はどこかのchを固定ではなくて「自動」にする！

・「チャンネル帯域」は「160MHz」にする！

・「チャンネル帯域」にある「160MHzを有効化」にチェックを入れる！

Wi-Fiミレルというツールを使って家のヒートマップを作成してみたよ。

これが我が家の図面とWi-Fiアクセスポイントが置いてある場所。

そして、この図面を読み込んで計測した結果が以下

5GHzのヒートマップ

2.4GHzのヒートマップ

なお、上記の計測に使用したのはiPhone 13 Pro Max。

ちゃんとメッシュが有効になっていて範囲が広がっていることを確認！

こういう風に視覚的に確認ができるのは非常に良いですね。

また、2.4Gは壁を越えられるが、壁を越えにくい5G帯の方がベースが速いので減衰しても速いということも分かりました。

つまり5GHz帯だけあれば十分。

と思えたけど、 DFS干渉を考えると6GHzも有効ではある。ただ減衰が･･･

だけど、スイッチボットが2.4GHzしか対応してないのよねぇ。。。

Wi-Fi 7の後継機種を購入したので、この機種は会社に設置することにしました。

会社はWi-Fi 5のR7800×2台だったので、Wi-Fi 6に上がるので良いですね！

しかもメッシュには対応してないので、「SSID-5G-南側」、「SSID-5G-北側」みたいな感じで２つのSSIDがあったけど、今度はメッシュできるので楽になります。

と言うことで設置してWi-Fiミレルでヒートマップを作成。
ちなみに中央の倉庫内にあるSynologyはVPNルーター機能がメインであり、Wi-Fiは無効化で運用。
そして倉庫の両角にマグネットフックで引っかけてアクセスポイントを設置しています。

旧環境が下記。

旧Netgear R7800_DD-WRT右 5GHzのヒートマップ

Wi-Fi5なので、右側に設置したアクセスポイントに繋いでいるときは左側では遅くなります。

特に僕の席は左下の155Mbpsのところ。

旧Netgear R7800_DD-WRT左 5GHzのヒートマップ

左側に設置したアクセスポイントに繋いでいるときは、当然ながら右側では遅くなります。

タバコを吸う人は右端のベランダで吸ってるようですが、ここはほとんど繋がりません。 

新ASUS RT-AX88U×2台メッシュ 5GHzのヒートマップ

さすがメッシュ！
オフィスのどこでも安定です！

5GHz帯のASUSのRT-AX88U×2台（Wi-Fi 6）と

5GHz帯のネットギアのR7800（Wi-Fi 5）の比較するとこんな感じになりました。

速度はだいたい2倍！

それでいて、どこでも安定して繋がっています。メッシュの偉大さを感じますね！

Wi-Fi 6機器としての性能は申し分ないです。

ワイヤレス通信も速いし、電波も安定。性能的な文句はありません。

一つだけ改善して頂きたい点があるとすれば、それは横置き専用の形状になっていること。

底面に穴を付けて壁掛けもできるようにして頂きたいと思います。

2025/2/1追記

底面にある壁掛け用の穴がゴムで埋まってるそうで、外した記事がありました。

わざわざゴムで隠さなくてもいいのにと思ってしまうけど・・・埃が内部に入らないようにとか？

謎ですね。

実際に底面の２カ所の目隠しを外して、マグネットフックで設置できました♪
これは良かった。

僕がRT-AX88Uを買ったのは2020年4月23日。

製品発売日は2018年12月21日。

そして、同じ筐体で有線LAN×２が2.5GHzになったRT-AX88U Proという兄弟バージョンが2023年2月8日発売。

なんと、ファームウェアが88Uと88U Proで共通？

そんな事もあるからか、いつまでもファームウェアが出続けます！

これは嬉しいですね！

EOSリストに掲載されるのはいつだろうか？

■ASUS製品サポート終了リスト

本製品はUSBメモリを繋げてNASとして使用することも出来ます。

更に「AiCloud」機能を有効化すればWeb公開してクラウド領域として使用することも可能です。

その「AiCloud」が乗っ取られてbot化してる不具合が発表されました。

まぁね、世の中には完璧な物は無いから仕方の無いことです。

Windowsだって毎月アップデートあるんだもん。

問題はちゃんと修正パッチ出すかどうかです。

これについては、すぐに提供されているの嬉しいことです。

■ASUS製Wi-Fiルーターから「AiCloud」の脆弱性悪用とみられる通信が増加

更にセキュリティ履歴を参照すると、今回のは影響範囲が大きいと判断したのかEOLになった製品(ファームウェア3.0.0.4_382 series)にも修正ファームウェアがリリースされる状況。

2025/1のファーム更新の際には3.0.0.4_382 seriesは更新されてなかったのにね。

これはASUSの優しさですね。

■ASUS Product Security Advisory

04/18/2025 ASUS Router AiCloud vulnerability ∇
Firmware
3.0.0.4_382 series
3.0.0.4_386 series
3.0.0.4_388 series
3.0.0.6_102 series

CVE
CVE-2025-2492

01/02/2025 ASUS Router AiCloud vulnerability ∇
Firmware
3.0.0.4_386 series
3.0.0.4_388 series
3.0.0.6_102 series

CVE
CVE-2024-12912
CVE-2024-13062