hgot07 Hotspot Blog

主に無線LANや認証連携などの技術についてまとめるブログです。ネコは見る専。

PoC: Pocket-Sized Mobile OpenRoaming Routers (2021)

Proof-of-Concept Mobile OpenRoaming routers based on OpenWrt.

Probably the smallest in the world? :-)

Mobile OpenRoaming router (Mango)

Mobile OpenRoaming router (Mango)

Variations

Mobile eduroam/Cityroam/OpenRoaming routers

Mobile eduroam/Cityroam/OpenRoaming routers
  • Previous mobile eduroam/Cityroam/OpenRoaming routers based on MikroTik hAP ac and hAP ac lite (2020)
    ("lite" cannot be used in Japan due to the radio conformity regulations.)
  • New router based on GL.iNet GL-MT300N-V2 (Mango) (2021)
    (2.4GHz band only)
  • New router based on GL.iNet GL-AR750 (Creta) (2021)

 

Features

  • Based OpenWrt 21.02.0-rc3 (as of writing) (firmware: Mango, Creta)
  • Truely pocket-sized.
  • Fully-managed mobile router emitting eduroam, Cityroam, and OpenRoaming.
  • Fast VPN tunnel by WireGuard to protect user communications from owners, LAN operators, etc. RADIUS traffic is also protected.
  • Easy operation: Simply connect the LAN and USB power, and the service will be up.

Mango with LAN & USB cable.

Mango with LAN & USB cable.

Back side of Mango.

Back side of Mango.

Passpoint (aka Hotspot 2.0) is available.

Passpoint (aka Hotspot 2.0) is available.

Android device connected by Passpoint.

Android device connected by Passpoint.

 

Current limitations

  • WireGuard VPN often fails to re-connect to the server, probably due to an issue specific to this target (Mango). It works well on Creta, though.
  • Only wired network is supported for the uplink. There's no Wi-Fi uplink support. Cannot go through web-based login at the venue.
  • There's no user interface for the owner to change any mode. (Hard to solve due to the lack of admin/normal user separation in OpenWrt)
  • WireGuard cannot go through at some venues using tough network filters.
  • Wi-Fi performance may not be so good. No MIMO. No Wi-Fi 6.

 

※ 国内での利用は技適の確認が必要です。あるいはGL.iNet製FWのバージョンが上がるのを待つか。

--

 

GL.iNet Beryl (GL-MT1300) インプレッション

Mango (GL-MT300N-V2)がめっちゃかわいい上に、性能も素晴らしかったので、同社の製品からは目が離せません。製品はOpenWrtベースでつぶしが利き()、技適もこまめに取ってくれるすばらしい会社です。

国内導入から少し日数が過ぎてしまったのですが、実験用にまとめ買いしたBeryl (GL-MT1300)を使うときが来たので、まずはインプレッションを。

ちっちゃっくないよ!

本当に小さくはないです。CretaやBrumeからちょっと大きいぐらいかと思っていたら、結構違いました。Pocket-Sized Travel Router って書いてあったやん!・・・・・(ノ`Д´)ノ彡┻━┻

往年のVAIO Pシリーズですねわかります。

写真の紫の方がBrume (GL-MV1000)

Beryl & Brume

Beryl & Brume

Beryl (bottom) & Brume (top)

Beryl (bottom) & Brume (top)

電力も大きめ

Brumeの定格が5V 2Aなのに対して、Berylは5V 3Aと表示があります。Brumeはその辺に転がっているACアダプタやPCでも平気だったりするのですが、Berylではアダプタを選びます。ちなみに、付属のアダプタはこれで、本体サイズもちょっとアレですが、ケーブルが太くて邪魔です。

Beryl付属のACアダプタ

Beryl付属のACアダプタ

ますます携帯用途からは遠ざかりました_('、3」∠)_

ちなみに、MangoやCretaはほんのり温かい程度、Brumeはちょっと熱めですが、Berylは本体のサイズが大きい分だけ熱が分散しているのか、Brumeほど熱い感じはしません。

 

まだまだ青い……

ちょっと古めのCretaは、応答速度にイラつくことが多目ですが、Berylは新しいだけあって、サクサク動く感じです。サクッと初期設定とアップデートを終わらせて、いざ細かい設定を……あれ?

Advancedメニューが、ない、ないよ!

まさか封じられてしまったのかと心配したのですが、何のことはない、GL.iNet独自メニューのPlug-insからluciのパッケージを導入すれば、Advancedメニューが出てきます。

さて、これで喜ぶのは早かった……

LuciのWireless設定では、SSIDのスキャンが動かないとか、接続状態が検出できないとか、WPA2-PSKがなくてOpenとWEP(!)しか選べないとか、なかなか困った状況でした。それっぽいパッケージを入れまくってみたのですが、解決せず。[2021/7/27追記] 下に若干追記しました。

ちなみに、GL.iNet謹製のメニューの方では、WPA2-PSKの無線LANにも正常に接続できました。sshログインして /etc/config/wireless を覗いてみても、きちんと設定されています。

というわけで、OSがまだ青々としているようです。OEMではないOpenWrtに入れ替えてしまう手もあるかもしれませんが、こちらは未確認で進行形

 

TIPS: ちなみに、一度luciのメニューに入ってしまうと、192.168.8.1 にアクセスしてもLuciが強制されてしまって、GL.iNet ADMIN PANELに戻れなくなることがあります。その場合 http://192.168.8.1/? にアクセスすれば戻れます

 

[2021/7/27追記]

システムが吹っ飛んだ!_(゚。3」∠)_

どうやら現在のバージョン(3.201)にバグがあるようで、luciでパッケージの削除を行っていると、肝心のluciやweb uiまでも吹き飛ばしてしまうみたいです。泣く泣くリセットボタンでファクトリーリセットするのですが、もし救い出したい設定などがあるなら、sshログインを試してみる方法があります。

> ssh root@192.168.8.1
root@GL-MT1300:~# opkg update
root@GL-MT1300:~# opkg install luci
root@GL-MT1300:~# reboot

リセットボタンを10秒ぐらい押して、リセット;;

パッケージ削除は、バージョンが上がるまで避けた方がよいでしょう。

 

[2021/7/27追記]

Wireless設定を使いやすくできる?

前に書いたとおり、そのままではsshやluciで無線LANの設定が満足にできません。kmod-mac80211-hwsim をインストールすることで、少し改善の兆しが見えたのですが、結論を言うとだめです

kmod-mac80211-hwsim を入れると、iw phy コマンドでデバイスが見えるようになります。下図のように、luciのWireless Overviewに、radio0, radio1というデバイスが生えてきます。

Wireless Overview (初期状態)

Wireless Overview (初期状態)

Wireless Overview (kmod-mac80211-hwsim導入後)

Wireless Overview (kmod-mac80211-hwsim導入後)

新しくできたradio0, radio1の方なら、WPA2-PSKやWPA2-EAPの選択も見えたのですが、なぜか設定しても正常に動きません。

何の成果も得られませんでした!

luci側での設定は諦めるしかなさそう。

WPA2 Enterpriseでの接続も頑張ってみたのですが、GL.iNet側のインタフェースがダメダメで、/etc/config/wireless や /etc/config/ssids をいじるぐらいでは接続できませんでした。さぁ、こまた……

 

[2021/7/30追記] 一応ここに、OpenWrtの新しいパッケージがあります。21.02.0-rc3を試してみたのですが、Access Pointの電波が出ないとか、WireGuardをオフにすると元のLANにdefault routeが戻らない(ネットに出られなくなる)とか、まだまだ青々としているようです。

 

サイズにこだわるなら……

Berylは、高性能が欲しい人向けです。

小さいは正義!な人には、残念ながらお奨めできません

Brumeはかわいいのですが、残念ながら無線LAN機能がありません。Wi-Fiモジュール付きのGL-MV1000Wというモデルもあるのですが、市場にあまり出回っていません(技適もない?)。

Cretaは、やはりちょっと古すぎる感じがあるので、となると Slate (GL-AR750S-Ext) でしょうかね。これも少し熱いと言われていますが、試してみたいところです。

 

To Be Continued... (マテ

 

 

 

 

 

Passpointはどこまで進んだのか (2021)

以前書いた記事↓から、なんと1年半も経っていました。今回はこの続編のようなものです。

hgot07.hatenablog.com

結論から言うと、ほとんど変わっていません!w

とりあえず、必要な定義から。

  • PasspointとHotspot 2.0は同じもの (少なくとも仕様上はな!)
    基地局メーカーではHotspot 2.0の表記が多いのですが、名前の分裂が問題となり、Wi-Fi AllianceとWBAではPasspointの方を積極的に使うこととされています。
  • 次世代ホットスポット / Next Generation Hotspot (NGH)の名称はフェードアウト
    マーケティング的な風呂敷として便利な言葉でしたが、OpenRoamingのような具体的なシステムが登場してきたので、WBAでは積極的に使わない方針のようです。

 

Passpoint Release 3からどうなった?

前回執筆時の2020年1月時点で、Wi-Fi CERTIFIED™ Passpointの仕様はRelease 3が出ていましたが、その後の改訂はありません。

ざっくり言うと、SSIDに依らずに自動接続できる仕組みを規定したRel. 1が登場し、Online Sign-Up (OSU)などを追加したRel. 2が出て、さらにVenue URLやOperator Icon Metadataなどの機能を追加したRel. 3になりました。

なぜ最近改訂がなかったのかというと、「すぐに必要になる新たな機能が無かったから」だろうと思います。いや、課題は色々と残っているのですが、少なくともどう実装すべきかという高レベルの話には至っていません。

そもそもPasspointは規格(仕様)なので、ある程度固まってきたら、そう頻繁に変えるようなものではないですよね。つまり、Passpointという規格に従って、エンドユーザ向けのサービスの開発が進んできたら、自然とその名称が後ろに隠れていくものでしょう。802.1Xなんて聞いたことがなくてもeduroamやd Wi-Fiが使えるみたいに。

 

Passpoint Release 2, 3対応の基地局がない!?

一番いいのを頼む

どうせ買うなら最新のものを……、というわけでPasspoint Rel.3対応の基地局を探そうとすると、ない!? そもそもPasspoint対応すら仕様表に書かれていなかったりします。

一応、対応製品はWi-Fi AllianceのProduct Finderで探すこともできます。(登録が遅いし、掲載されていても非対応な機種とかあって、信頼性に難ありなのですが……)

www.wi-fi.org

 

それでは、本当にRel. 2やRel. 3に対応した製品がないのかというと、そうでもなくて、部分的に機能が少しずつ追加されている感じです。例えば、UniFiならこんな設定があり、OSUに対応しているっぽいです。ぽい。

OSU of UniFi

OSU of UniFi

どうもRel. 2以降の認定が進んでいないようですね。Rel. 2のとある機能の敷居が高くて嫌われている疑惑が……、しらんけどw

Wi-Fi Allianceには、仕様策定の他に、認定プログラムを実施する機関の顔がありますので、そこのビジネスが滞ると……(ウワナニヲスル

 

Passpoint Release 3は来ないのか

なんとも雲行きの悪い話を書きましたが、悲観することはないです。

OpenRoamingが本格的に立ち上がったことで、ローミングサービスの細かなUI/UXも議論されるようになってきました。そこでよく話題に上るようになったのが、Venue URLやOperator Iconです。Rel. 3の認定プログラムを通さなくても、基地局ベンダがこれらの機能を追加してくる可能性は高いです。

以前のエントリから引用します。

"Operator Icon Metadata"や"Venue URL"は、例えばフリーWi-Fiにおいて、サービスを提供している事業者やスポンサーはどこかといった情報を、利用者に伝えるのに役立つでしょう。1X認証は、自動接続されて、標準ではキャプティブポータルがないため、従来はスポンサーの不満がありました。

 

※ 余談ですが、お宅の無線LANルータ、Wi-Fi CERTIFIED™のロゴが付いていますか?最近のWi-Fi 6対応機なら付いているでしょうが、少し前の11acのモデルでは、付いていない製品もありました。なぜでしょうね~

 

Passpointの今後

先に書いた通り、仕様としてのPasspointは、次第に利用者の目には見えない、裏方に回っていくものと考えられます。ぇ、今までも知られていなかったって?あっ、はい_('、3」∠)_

なので、サービスのプロモーションとしても、Passpointの名前はあまり前面に出て来なくなるのではないかと思います。その代わりに、OpenRoamingのように、具体的なサービスの名称の方が、一般的になってくると予想しています。

 

Passpointで遊んでみたい?

設定方法がまとまった資料は、こちら↓がお奨めです (というか現状これしかない)。

booth.pm

Passpoint対応のアクセスポイントの中でも、比較的安価で設定もいじりやすく、安定しているのはAruba AP-200シリーズでしょう (注: Instant OnはPasspoint非対応, 書籍のガイドにはPasspoint記載なし)。しかし、AP-200シリーズは終売になってしまいました。執筆時点で、AP-203Rはまだ若干の流通があるようです。ただし、AP-200シリーズは今となっては少しトロいので、あまりお奨めではないです。

2021年の電子部品不足から、Aruba APは軒並み国内在庫がなくなっています。

安い基地局をお探しなら、こちらもどうぞ。

hgot07.hatenablog.com

面倒がなくて、一発で安定して動くという点では、Merakiが楽ちんですよ。安くはないけど。(リクエスト出さないとHotspot 2.0が有効にならないのは、今でもそう?)

 

おわり

アライドテレシスAT-TQm5403のPasspointを試してみる

海外勢から遅れに遅れて、やっとのことで国内メーカーからPasspoint (Hotspot 2.0)対応の無線LANアクセスポイントが出てきました。アライドテレシスAT-TQ 5000シリーズです。

私の記憶が確かならば……、Passpoint対応国産機第一号は「ポジモ」なのですが、一般用途ではこの5000シリーズが最初でしょう。パナソニックは実機が出たかどうか怪しい。

ハードウェアは2018年発売ですが、Passpointは2021年春のファームウェア(Ver.6.0.1-5.x)から対応しています。

基地局メーカーではHotspot 2.0の表記が多いのですが、名前の分裂が問題となり、Wi-Fi AllianceとWBAではPasspointの方を積極的に使うこととされています。

今回、AT-TQm5403を入手したので、これでPasspointを試してみました。小文字のmの付かないAT-TQ5403との違いは、コントローラでの管理台数と最大接続台数です。型番の末尾に付く -Z1 などの記号は、サポートサービスの区別です。

もし既に学校や図書館、会議施設等でこの5000シリーズを導入しているなら、訪問者のために、WBA OpenRoamingによるセキュアな公衆無線LANの提供も検討するとよいでしょう。

 

まずは結果!

ほい!基地局Cityroamの認証基盤に接続し、GlobalReachから入手したOpenRoaming用プロファイルを使って、Passpoint経由で無事に接続されました。

Passpointによる接続

Passpointによる接続 (iOS 14.5)

ハードウェア

こんな感じです。家庭用と比べたら結構大きいです。

AT-TQm5403

AT-TQm5403

AT-TQm5403 (rear)

AT-TQm5403 (rear)

IEEE 802.3afのPoEアダプタでも縮退モードで動くようですが、802.3atまたはACアダプタを使うように警告が出ます。

 

ファームウェアのアップデート

世の中には、保守契約を結んでいないとセキュリティアップデートすら提供しないひどいメーカーもあるのですが、アライドさんの基地局のサポートは良心的です。ユーザ登録も特に要りません。ウェブサイトから最新のファームウェア (執筆時点でVer.6.0.1-6.1) をダウンロードして、基地局に流し込むだけです。

 

Passpointまわりの設定

無線LANRADIUS認証の設定については、ざっくりと省略。無線LANのバンド数が多く、2.4GHz帯の他、5GHz帯がW52/W53, W56と分かれているのが、ちょっと面倒です。Merakiなら特に意識することなく一括で認証周りの設定が済むのですが……。(バンドステアリングとかどうなっているのでしょう?)

とにかくマニュアルです。802.11uとHotspot 2.0に項目が分かれています。

設定項目が多くて、Passpoint初心者は面食らうと思いますが、ある程度慣れていてもちょっと驚くぐらい面倒なので大丈夫(アレ?)。正直、見通しがかなり悪いです。

イメージはこんな感じ。まずはHotspot 2.0の方から。

Hotspot 2.0 Settings

Hotspot 2.0 Settings

Passpointを有効にしたいバンドとSSID (仮想AP, VAP)を選択してから、Hotspot 2.0 Settingsのタブを開きます。とりあえず設定が必要なのは、Operator Friendly NameとOperating Class Indicationぐらいです。下部にOSU (Online Sign-Up) の文字が見えるので、もしかしたらPasspoint Release 2にも対応しているのかも (今回は使用せず)。

次に、802.11u Settingsを開くと、こんな感じ。

802.11u Settings

802.11u Settings

こちらは色々といじる必要があります。多くの項目が、説明的なラベルのついた選択肢ではなく、生の数値で入力する仕様です。これは厳しい><

こんな感じで設定しました↓

  • Access Network Type: 3 (無料のパブリックネットワーク)
  • Internet Access: 有効
  • Venue Group, Type: 0, 0 (不特定の場所)
  • Homogeneous ESS Identifier (HESSID): (当該SSIDMACアドレス)
  • Roaming Consortium List: (OpenRoaming用のRCOI)
  • Venue information: eng:Cityroam
  • Domain Name: cityroam.jp
  • IP Address Type Availability: 14 (NATが1回のプライベートIPv4アドレス)

これら以外はデフォルトのままです。

Venue Group, Typeは、アライドのマニュアルにも代表的な値が掲載されているのですが、すべてを知るにはIEEE Std 802.11を見ないといけません。うーん、面倒。

今回、NAI Realmは登録していません。これも入力フォーマットが複雑で、マニュアルだけでは何を入れたらよいか分からないレベルです。

HESSIDは、ブランクに設定できるはずですが、設定を保存しようとするとエラーになります。仕方がないので、当該SSIDMACアドレスを入力しました。

以上、とにかく色々と分かりにくいので、改善を望みますMerakiならずっと楽に設定できるので、技術的にできないわけがありません。

バンドごとにPasspoint設定を入れるのも、非常に手間がかかります。本来は直交させるべき設定だと思います

素直に動いたのはご立派。Wi-Fi 6対応の6000シリーズでも早期にPasspoint対応してくれることを願います

 

終わり

 

 

 

IMSI Privacy Protection - SIM認証のプライバシ対策

キャリアWi-Fiでおなじみ(?)のSIM認証ですが、そのプライバシ保護についての話です。最近のスマートフォンでは、MACアドレスランダム化が実装されていて、第三者による端末追跡を困難とすることによって、プライバシ保護が実現されています。ところが、MACアドレスランダム化だけでは不十分でした。

この一年ほどの間に、Wi-Fi業界では(Google主導で) "IMSI Privacy Protection" と呼ばれる仕組みが議論されていて、これから端末などに実装されようとしています。その概略を紹介します。

[2021/6/18] 今後この方式が標準になるかどうかは未確認で進行形

IMSI: International Mobile Subscriber Identity; 国際的な加入者識別番号で、携帯電話の契約時に割り当てられ、SIMに書き込まれる。英語ではイムズィのように読む。

詳しい概略(?)はWireless Broadband Allianceのウェブサイトからダウンロードできます(要登録)。多少長い英文でもざくざく読んでいける人は、ここで当エントリはやめて、ソースを参照した方が確実でしょう。英文ソースの翻訳を記事にするつもりはなく、あくまで「こんなのもあるよ」程度の安い記事なので。

wballiance.com

とりあえず日本語でざっくり掴みたい人は、この先へどうぞ。

 

どのようなプライバシ問題か

無線LANのプライバシ問題やその対策について、以前にいくつか記事を書きました。

hgot07.hatenablog.com

hgot07.hatenablog.com

今回はどのようなプライバシ問題かというと、フリーWi-Fiでおなじみの、「端末(利用者)追跡」です。前の記事に書いたように、すべての追跡が悪いわけではないのですが、利用者の承諾もなしに追跡できてしまうことがプライバシ上の懸念となります

 

何が問題だったのか

前の記事では、認証方式としてEAP-TTLSやPEAPが使われている場合について書きました。SIM認証では方式が違い、EAP-SIM, EAP-AKA, EAP-AKA'が使われています。このうち、最近ではEAP-AKAまたはAKA'を使うのが一般的です。

これらのSIM認証方式では、EAPトンネルやouter identityといったものはなく、利用者の識別情報が平文で空中を飛ぶことになります。具体的には、識別情報として使われるIMSIが、暗号化されない形で利用されていました

基地局(AP)の中にあるオーセンティケータと端末の間では、次のようなやり取りがあります。まず、オーセンティケータから端末に対して、EAP-Request/Identityというメッセージが送られます。これに対して、端末はEAP-Response/Identityを返しますが、このとき <prefix><IMSI>@<NAI realm> の形式で識別情報が渡されます(*1)。NAI realmは、 wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.​org の形式で、MNCがMobile Network Code、MCCがMobile Country Code (両方を合わせてPLMN-IDと呼ばれる)を表します。

IMSIが平文のままだと、どのようなプライバシ上の問題が生じるでしょうか?

悪意ある攻撃者が、キャリアWi-Fiの利用者の無線通信を傍受していたり、キャリアWi-Fiを装った偽基地局を設置していたりすると、利用者が気付かないうちに、IMSIが攻撃者に知られることになります。攻撃者と書きましたが、実は、こっそりと無線LANの利用者を追跡しようとしている、追跡ビジネスかもしれません

IMSIは利用者に振られた永続的なIDなので、それが書き込まれたSIMを使い続ける限り、地球の裏側まで追跡されうるということです

 

[2021/6/18追記] *1: 一部の端末は、どのSSIDに対しても1X認証で接続を試みるようです。そのため、WPA2 Enterpriseの無線LANシステムを運用していると、通りすがりの人のものと思しき端末から接続が試行され、RADIUS proxyのログに 3gppnetwork.org のレルムでLogin incorrectの記録が残ります (キャリアのIdPに接続されていないためOKは出ない)。このログでは、prefix+IMSIが丸見えのものが多数ですが、以下のようにユーザ名部分が匿名になっているものもあります。手元の2019年のログには既に匿名のものが見えます。(詳細は調べ切れていません)

  • aka_anonymous@wlan.mnc010.mcc440.3gppnetwork.org (ドコモ)
  • sim-encr_softbank@wlan.mnc020.mcc440.3gppnetwork.org (ソフトバンク)
  • anonymous@wlan.mnc260.mcc310.3gppnetwork.org (T-Mobile US)

 

EAP-AKAの場合

端末は、EAP-Request/Identityを蹴ることができるようです。

 Ω ΩΩ<な、なんだってー!!!

ところが、この蹴り方がきちんと定義されていなくて(ぇ?)、下手に応答しないように実装すると、接続できない問題が生じるようです。

EAP-AKAの場合、続いてオーセンティケータからEAP-Request/AKA-Identity (AT_PERMANENT_ID_REQ) が送出され、端末がEAP-Response/AKA-Identityを返します。これには  AT_IDENTITY が含まれており、形式はこれまた <prefix><IMSI>@<NAI realm> です。(ダメじゃん)

一応、AT_IDENTITY に仮名ID (pseudonym)を返す方法も規定されていますが、認証成功のためには後に素のIMSIを送ることになって、全然保護になっていません。(この辺はざっくり省略)

 

IMSI暗号化によるプライバシ保護

そこで、どうするかというと、認証に必要なIMSIを含むPermanent Identityを RSAES-OAEP(Optimal Asymmetric Encryption Padding, Sect. 7.1 of RFC8017) を使って暗号化します。ここで、暗号文にランダム性が入るのがキモです

Permanent Identity = <IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org

Encrypted Permanent Identity = Base64(RSA-OAEP-SHA-256(Permanent Identity))

端末は、こうして得られたEncrypted Permanent Identityを AT_IDENTITY に詰めて、オーセンティケータに送り返します。このときの AT_IDENTITY の形式は、`\0`<Encrypted Permanent Identity><,<attribute>=<value>>となります。IMSIがランダム性を含む暗号に変換されているため、盗聴されても追跡が困難になります

RSAの鍵を扱うために、公開鍵暗号基盤 (PKI) を使います。

# おうふ、また鬼門のPKIか_('、3」∠)_

 

 

 

書評:「これ1冊で丸わかり 完全図解 無線LAN入門」(日経NETWORK)

前に以下のエントリで紹介したムック本「無線LAN技術 最強の指南書」(日経BP)の内容を大部分引継ぎながら、構築についての解説を加筆したものです。

 

 

「指南書」の方はKindle Unlimitedなら0円で読めますが(2021/5時点)、買うなら新しい「完全図解」の方がよいでしょう。

まず、大部分は指南書と同じなので、その部分についての書評は以前のエントリをご覧ください。

 

変わったところ

新しい方の目次は以下のとおりです。指南書と同じ部分に〇、追加部分に+を付けてあります。

【第1部 無線LANの基本を学ぶ】
 〇第1章 イラストで学ぶ無線LANのき・ほ・ん
 +第2章 令和時代の無線LAN

【第2部 無線LANの最新技術を知る】
 〇第1章 無線LANの最新技術
 〇第2章 Wi-Fi 6の実力
 +第3章 Wi-Fi 6導入のポイント

【第3部 無線LANの周辺技術を学ぶ】
 +第1章 徹底理解PoE
 +第2章 IoTのつながる仕組み

【第4部 無線LANの疑問を解く】
 〇第1章 試して分かった!無線LANの素朴な疑問

【第5部 無線LANの構築方法を学ぶ】
 〇第1章 これなら使える無線LAN
 +第2章 愛され無線LAN構築術

 

指南書から削られた部分は、以下のとおり。

【第3部 無線LANを構築する】
 ー第1章 無線LAN構築 六つの鉄則
 ー第2章 無線LANサイトサーベイ入門
 ー第3章 こんな無線LANはイヤだ!
 ー第4章 ネットワーク構築のツボ
    レーダー波の影響を防ぐ無線LAN構築法
 ー第5章 ネットワーク達人の知恵
    無線LANの認証 

 

この削られた第3部、実は、微妙な書き方が多かったところでした。鉄則という書き方をされると、もうそれらが絶対であるかのように見えてしまう罠があります。第3章では、誤りの方をデカデカとタイトルにしていたので、読んでいて気持ち悪かったものです。はっきり言って、この部分はもはや読まなくても大丈夫でしょう

ミドルレイヤを主に扱っている私としては、無線LANの認証の話が削られたように見えて一瞬残念に思ったのですが、実は「令和時代の無線LAN」に似たような話題が含まれています。指南書の方の記述は、色々と古かったり怪しかったりするところもあったので、この部分がアップデートされたのは良かったです。

 

新しい話題

無線LANシステムの動向が(当時)最新のものにアップデートされています。その上で、構築に関する説明が充実しました

「令和時代の無線LAN」の章では、比較的新しい技術が解説されています。安定、安全、そして使いやすいシステムを構築するという、問題解決指向で技術が紹介されています。ただ、ボリュームはないので、最初のとっかかりになる程度でしょう。それでも、用語が分かった時点で、詳しい情報にたどり着くのには大いに助けになるでしょう。

表紙にも記載のあるPoEやIoTの話は、いざシステムを構築しようとすると情報にたどり着くのに苦労するところでもあるので、関連技術として取り上げられたのはよいです。

「愛され無線LAN構築術」の部分は、一般化しにくい細かいネタが多いように思います。ただ、システム構築上は「ここが危険なのか」「あぁ、そうすればいいのか」などと、色々と参考になるでしょう。ただし、「MACアドレス認証」という、本来は認証とも言えないシロモノの記述は、残念でした。Web認証も、キャプティブポータルが抱える問題まで踏み込むか、せめて注意喚起ぐらいは欲しかったです。セキュリティ周りの記述については、こうすればよいというより、次善の策としてこういうのもあるよという、事例紹介と思って読んだ方がよいです

 

2.4GHz帯無線LANのチャネルはぶつけてしまった方がよい

もう少し正確に書くと、
2.4GHz帯無線LANのチャネルは、少しずらすよりは、ぶつけてしまった方がよい(スループットが上がる)」です。

 

無線LANがよく設計されたホテルや会議場、空港などでは、下の図のように1-6-11chに綺麗に山が立っています。

 

1-6-11ch

1-6-11ch

上はシドニー空港(SYD)の例ですが、おそらく無線LANコントローラの自動割り当てによるものでしょう。12chに居るAPはダメな子です。あと、8ch付近にチャネルボンディングが有効なAPが居ますが、2.4GHzでこれをやられると、周囲が大迷惑です。

次の例はどうでしょう?

bad channel assignment

bad channel assignment

よく見ると1-6-11chにホテルWi-Fiが見えますが、持ち込みのAPが隙間に入っていて、かなり酷い電波状況です。実際、この時の無線LANはまともに使える品質ではありませんでした。

 

なぜ1-6-11ch構成が一般的なのか

2.4GHz帯の無線LANでは、隣り合うチャネルのスペクトルが大きく重なっているため、この重なりをできるだ避けるようにチャネルを割り当てようとすると、全部で13ch (USでは11)ある中で3つしか取れません

例えば1chと3chのように、隣接するAPのチャネルが少しだけずれていた場合、隣の通信はノイズになり、データ転送のエラーが増えることになります。

このため、多数のAPを並べるような用途では、1-6-11chを使うのが業界のベストプラクティスになっています。

[2021/5/21追記1] EUでは日本と同じ13chが使えるので、少しだけ重なりを持たせた4チャネル構成(1-5-9-13ch)というのも検討されていました。しかし、隣に3チャネル構成のエリアがあると当然干渉しまくるので、使わない方がよいとする文書が多数あります。(私は4チャネル構成を見たことがありません)

 

チャネルがぶつかったらもっと酷いことになるのでは?

無線LANシステムが一つしかない場合でも、ある空間に複数のAPから同じチャネルの電波が届くことがあります。このような環境で、複数の端末が異なるAPと通信していると、同じチャネルの通信が時空間でぶつかり、スループットが低下するでしょう。

「それなら、スペクトルが多少重なっても、チャネルをずらした方が得策では?」

どうでしょうね?既に1-6-11chが使われているなら、隙間の3chを使ってみるとか?

結論としては、近接したチャネルを使うよりも、同じチャネルを使ったほうが「マシ」です。次節で見てみましょう。

 

実験!

twitterで() 識者に紹介されたビデオです↓

www.youtube.com

近いチャネルを使うよりも、チャネルをぶつけてしまった方が、スループットへの影響が若干小さいことが分かります。

この理由として、以下のような説明を見かけたことがあります。どれだけ合っているのかは不明ですが。
「隣接チャネルの信号は、単純なノイズとして(電子レンジと同様の)、妨害になる。同チャネルの通信ならば、APや端末は互いに制御パケットをデコードできるので、ある程度の制御が可能」

2011年のビデオなので、11nの機材が使われていますが、11acや11ax、MIMOではどうなるのかも気になるところです。あと、機材によって違いが出るかどうかも、気になります。

 

[2021/5/20追記] 参考まで、チャネルをぶつけた場合に有意な差が出なかったケースもあるようです。

 

[2021/5/21追記2] 上の例で「なーんだ、スループット上がらないじゃん!」と思うかもしれませんが、この結果が興味深いのは、「同チャネルに設定しても隣接チャネルと比べて大幅に性能劣化するわけではない」ところでしょう。

1-6-11chが埋まっている場合を考えてみます。例えば隙間の3chや4chを使おうとすると、自分は両側(1ch, 6ch)から干渉を受けることになり、逆に両側に干渉を与えることになります

 

[2021/5/21追記3] Ciscoが11bで4チャネル構成を試していたときの文書を見つけました。(11bは古いぞ!)

  • "Channel Deployment Issues for 2.4-GHz 802.11 WLANs,"  Cisco Systems Technical References, 2004.  (Ciscoリンク切れ)

このテストでは、1chをぶつけた1, 1, 6, 11ch構成と、間隔を詰めた1, 4, 8, 11ch構成を比べており、前者でクライアントあたり601.1KB/s、後者で348.9KB/sの結果とのこと。比較条件が当記事の主題と異なるのですが、以下の技術的考察が関係ありそうです。

Note that even when two access points shared channel 1, the overall performance was greater than in the four-channel scenario. This is because the CSMA protocol created a holdoff when the clients on the same channel decoded that the interference was another 802.11 signal. In the four-channel scenario, the client could not decode the interfering signal, reacted as if it was low-level noise rather than a holdoff, and sent the packet. This resulted in a collision and a retransmission on both clients.

 

結論

  • 2.4GHz帯で隣接チャネルの利用は避ける。4ch以上離せないなら、むしろ同一チャネルの方がマシ。
  • 2.4GHz帯では1-6-11chのみ使う。チャネルボンディング(HT40)は周囲に大迷惑なので禁止。
  • コントローラの最適化機能をうまく利用する。
  • もちろん、同じチャネルの強い信号が同じ空間に入らないように、基地局の出力を調整する(絞る)方がよい。
    (家庭向けのハイパワーモデルは、集合住宅ではよろしくない)

 

余談 (追記)

干渉を避けるために「5GHz帯を使え!」はその通りですが、電波の届く範囲が狭くなるのと、屋外利用に制約があるので、公衆無線LANでは使いにくい面もあります。

 

 

hgot07.hatenablog.com