
2026/05/27 1:41
OpenWRT での室内Wi-Fi 切り替え
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
ネットワークは、Cudy AX3000 アクセスポイントを用いたカスタム OpenWRT ベースのアーキテクチャへの移行を成功裏に完了し、レガシー 2.4GHz と近代 5GHz の周波数を厳密に分離しています。本構成はクラウドサービスやベンダー固有ソフトウェアの利用なく完全に動作しており、商用エコシステムに対し低コストかつオープンソースの代替手段を提供します。セキュリティについては、古いバンドにおける IoT デバイス向けに WPA2、新しいバンド向けに WPA3/SAE を実装し、初期にはいくつかのクライアント互換性问题が発生して手動介入が必要となりましたが、これを克服しています。技術的な課題は、集約管理システムを避けた上で、roaming 管理及びパフォーマンス計測のために usteer などのサードパーティ製ツールや collectd を統合する事で乗り越えられました。少数のログエントリーでペアワイズ鍵の欠落による潜在的な不安定性が示唆されていますが、移行により機器の roaming 動作が著しく改善し、5GHz バンドにおける「スティッキー」接続が減少しました。このプロジェクトは、標準ハードウェアとコミュニティ主導のファームウェア、Gitea などのオープンソースユーティリティを組み合わせることで、堅牢でクラウドフリーなネットワーク構築が可能であることを実証しています。
本文
Cudy AX3000 with OpenWrt and usteer: ロアミング最適化レビュー
2026 年 5 月 26 日の記事です。自宅ネットワークを OpenWrt に移行して数ヶ月が経過し、特に「ロアミング(ハンドオーバー)」の改善について具体的な対策と結果をまとめました。
環境構成の概要
ネットワーク分離戦略
- 2.4GHz 帯: IoT デバイスやレガシー機器との互換性を確保するため、WPA2 を採用したネットワーク。
- 5GHz 帯: 現代のクライアント向けに WPA3/SAE を採用したネットワーク。一部の古いデバイスは接続できず(意図せず)、それを受け入れることに満足しています。
- バックホール: 4 つのアクセスポイント(AP)を介して、2.5Gbe で安定動作しています。
- 管理方針: クラウド管理やベンダー固有のソフトウェアは一切使用せず、ローカルの SSH セッションで完全管理しています。
課題背景
- 自宅構造(エレベーターシャフト周辺)や微小な RF 妨害源(冷蔵庫など)により、iPhone や MacBook などの Apple デバイスが特定の AP に固執し、切り替えにくい傾向がありました。
- 初期設定では
や Fast Transition は有効化されておりログも確認可能でしたが、実際の切り替えはうまく機能していませんでした。802.11r/k/v
ロアミング改善への対応:usteer の導入
問題点の特定
- スティ어링(誘導)デーモンが動作しておらず、クライアント側でのみの判断でした。
- 結果:遠くの AP に固執し、信号品質が悪化するのに接続を維持しようとする状態が続いていました。
- 802.11k の制限: 隣接する AP のリストを提供できておらず、ホストが相互に情報を共有できませんでした。
解決手順
以下のコマンドを実行することで、4 つの AP に usteer とその管理インターフェースを適用し、初期設定(デフォルト)で動作させました。
opkg update opkg install usteer luci-app-usteer /etc/init.d/usteer enable /etc/init.d/usteer restart
デフォルト設定のポイント
- LAN 内での gossip メッセージングを有効化。
- IPv6 は無効化(ISP ルーターの安定性確保のため)。
- ログ出力レベルは中程度に設定。
802.11k 隣接リストの追加実装
usteer のみでは隣接 AP のリストがまだ埋まらなかったため、static-neighbor-reports パッケージを導入しました。
opkg install static-neighbor-reports /etc/init.d/static-neighbor-reports enable /etc/init.d/static-neighbor-reports restart
実装のポイント
- 帯域厳密: 2.4GHz の AP は 2.4GHz のみ、5GHz の AP は 5GHz のみを広告します(混在を防ぐため)。
- 相互確認: 各 AP に他方の情報を提供し、互いが見え、クライアントに適切な誘導ができるようになります。
改善結果と検証
5GHz 帯での顕著な変化
初期の状態と比較すると、以下のグラフ(Graphite データから生成)での変化が確認できます。
- SNR(シグナル対ノイズ比): 2.4GHz は依然として混雑環境ですが、5GHz では利用状況に目覚ましい変化が見られました。
- 登録 AP の明確化: クライアントが正しく所属する AP に切り替わることが確認できました。
- スティッキー・クライアント(固定接続)の解消:
- 初期:-90dBm と非常に弱い信号のまま接続されていたクライアントが大幅に減少。
- 現在:極端に弱いクライアント(-75dBm 以下)はほぼ消滅し、ロアミングが正常に行われている証拠となりました。
2.4GHz 帯の現状
- 改善: 4 つの AP のうち 2 つは改善または横ばいでした。
- 悪化: 残り 2 つはサンプル期間内で性能が低下しました。
- 完全な解消は困難ですが、IoT 機器を含む環境では妥当な結果としています。
注意事項とログ確認
システムに致命的な欠陥があるわけではありませんが、以下のログエントリーが発生した際に注意が必要です。
FT: Missing required pairwise in pull response from a peer AP
- このエラーは導入後、一度だけ確認されています。
- SAE と Fast Transition を活用しているため、環境変動により稀に生じる可能性があります。ログ監視を続けることを推奨します。
今後の展望と総括
メトリックの継続監視
- LLM にグラフ化スクリプトやクエリの作成を任せていますが、実時間のダッシュボード構築には時間を割いていません。
- しかし、Graphite のメトリックは保存され続け、ローカルの Gitea インスタンス にも設定データが格納されています。そのため、数ヶ月後のスポットチェックも可能です。
Cudy AX3000 の評価
- 好意的: クラウドコントローラーや複雑なメッシュ機能、特製アプリなしのシンプルな構成です。
- OS: OpenWrt
- モニタリング: collectd/Graphite
- 接続: SSH セッションによる設定確認
この構成の魅力は、「不具合が起きたとしても、私が検査可能な状態で起こるから」という点にあります。透明性とコントロール性が最高です。