hgot07 Hotspot Blog

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

Wi-Fi 7対応の基地局 エレコムWRC-BE94XS-B で遊んでみた

あれ?最近アイ・オー・データ機器のWN-7T94XRで遊んでいましたよね?

hgot07.hatenablog.com

あっはい……。色々と試してみたいことがあって、黒い方も買ってしまいました。

これです。(注: この記事にはアフィリエイトリンクが含まれます)

 

同じWN-7T94XRをもう一台買おうと思ったら、よく使う店からは早々に掃けていました。ハードはおそらく同じで、ファームウェアまで同じらしい (ファイルサイズが違うので要注意) ので、それなりに調査がおもしろそうです。

 

というわけで、ここでは WRC-BE94XS-B をいじってみて分かったことを、順次書き溜めていきます。アイ・オー・データ機器版の記事と合わせてお読みください。

 

外観について

大きさはWN-7T94XRと同じですが、側面に放熱穴のようなものが開いています。ただ、中がよく見えないので、放熱用というよりも意匠なのかもしれません。

WRC-BE94XS-Bの外観

WRC-BE94XS-Bの外観

WRC-BE94XS-Bの背面の様子

WRC-BE94XS-Bの背面の様子

文字が比較的読みやすいです。レイアウトは WN-7T94XR と完全に一致。

ブートの時間なども、すっかり同じです (要するにトロい)。中身は Qualcomm Immersive Home 326 で、これまた同じ。詳しくは前の記事をどうぞ。

 

性能調査……の前に環境紹介

HP EliteDesk 800G6 SFF (Intel Core™ i7-10700 @ 2.9GHz)の PCIe x16 スロットにIntel BE200とtp-link TX401 (10GbE)を載せました。

上位回線に SINET L2VPN 10Gbps を用意して、Ryzen 7 5800X搭載のLinux機をNAPT箱にしています。有線接続ではこんな ↓ 感じで、10Gbpsなので揺れ幅は大きいですが、まぁまぁです。(iperf3はNAPT箱宛て)

10Gbps回線のテスト

10Gbps回線のテスト

10Gbps回線のテスト (iperf3)

10Gbps回線のテスト (iperf3)

 

そくてい!

Wi-Fi 7の表示が出ているのに、なぜかリンク速度が2.4Gbpsで頭打ちな感じです。

Wi-Fi 7で接続された図

Wi-Fi 7で接続された図

「OS (Windows 11*) のサポートが保留されているため、Wi-Fi 7 の機能は現在利用できません。その結果、ドライバーのインストール後、インテル® Wi-Fi 7 製品は Windows* 11 上の Wi-Fi 6E 機能で機能します。」

な、なんだってー _(゚。3」∠)_

Windows 11のWi-Fi 7対応は24H2からということらしいです。

とりあえず、測定……

Speedtestの結果

Speedtestの結果

あれ、こんなもの?

iperf3の測定結果 (Wi-Fi経由)

iperf3の測定結果 (Wi-Fi経由)

有線はすべて抜いてあるので、値は正しいはず。なんで……

まさかCPUがサチっているとは考えたくないですが、一応、有線でも確認します。

 

有線接続での性能

WRC-BE94XS-B のLANポート (2.5GbE)にPCを有線接続してみると、このようになりました。

LAN端子の速度測定 (Speedtest)

LAN端子の速度測定 (Speedtest)

あれ?下りがおかしいような。

試しにiperf3で見てみると……

LAN端子の速度測定 (iperf3)

LAN端子の速度測定 (iperf3)

ちゃんと2.5GbEっぽい値になっています。

 

まだチューニングが足りないのかもしれません_('、3」∠)_

今後の伸びしろに期待。

 

あと、Wi-Fi 7対応でちゃんと速度の出る子機が欲しい。

 

2024/5/27時点では以上です。

 

 

 

Wi-Fi 7対応の基地局 アイ・オー・データ機器WN-7T94XR で遊んでみた

Wi-Fi 6E対応機器 (特に端末側) もまだ十分に普及していないのに、Wi-Fi 7の基地局が発売になり、しかも初物にしては3万円台 (実売は2万円台) というお手頃価格で出てきたので、うっかり()買ってみました。  (注: この記事にはアフィリエイトリンクが含まれます)

アイ・オー・データ機器のこれです。

製品情報はこちら。中身のハードウェアが同じOEMと思われるエレコムの製品も、一緒に出ています。

 

ここでは、WN-7T94XRをいじってみて分かったことを、順次書き溜めていきます。

ただし、普通の使い方については個人的にあまり興味がないので、そちらは他に多く出てくるであろうレビューに譲ります。

 

開けてびっくり!?

でかい……

3.5インチHDDと並べてみました。

3.5インチHDDと大きさ比べ

3.5インチHDDと大きさ比べ

そうでもないなと思いましたか?これではどうでしょう?

まんがタイムきららキャラット3冊分

まんがタイムきららキャラット3冊分

ほぼ、まんがタイムきららキャラット3冊分の容量でした。

しかし、大きいといっても、家庭用ハイエンド機にありがちなツノがニョキニョキ生えたモデルと比べると必要な容積は少ないし、見た目がすっきりしているのは好印象です。座りがよくないのが少し残念 (地震が不安)。

 

リアパネルの刻印が薄くて、暗めの部屋と悪くなってきた目では、読むのに苦労しました。

リアパネルの様子

リアパネルの様子

出荷時にはオート設定になっています。電源を入れると、ネットワーク端子のLEDが点くまで結構な時間がかかりました。端末がDHCPでアドレスを受け取ると、キャプティブポータルで設定画面が勝手に出てきます。

さっそくログインしてみると、自動検出で画面がグルグルする表示が続いて、手動設定とか一切受け付けません。ここはちょっと不満。

一度初期化が終わると、あとは電源投入から1分ぐらいで立ち上がるようになります。我慢して待ちましょう。(新しいプロセッサにしてはちょっと遅くないかい?)

 

中身のハードとソフトは?

プラットフォームは Qualcomm Immersive Home 326 です。トライバンド2+2+2ストリーム / 総合10Gbps という仕様です。

調査中に IPQ5332 という表示を見かけましたが、こちらは上位モデル 3210 (10ストリーム) の型番なので、ソフトウェアが共通化されているのでしょう。

ログインすると URL に cgi-bin/luci とか見えるので、お察しのとおり、OpenWrtベースです。OpenWrt 19.07ベースのQualcomm SDK (QSDK) のようです。

 

root取れる?

いきなりそれかい!(笑)

まぁ、それが 最優先事項 なのですが……

OpenWrt だからなんとかなるんじゃないのー、としか言えませんが。

なお、SSH (dropbear) は無効化されています。

 

設定ファイルを通じて設定投入できる?

バックアップファイルが openssl で暗号化されているので厳しいです。(長い) 鍵がないと展開できません。

 

GL.iNetみたいなLuCIはある?

ありません><

OpenWrtのインタフェースは解放されていません。
(あれば、逸般人に大ヒットしそうなものですが)

 

Passpointは使える?

使えません。(確認済み) _('、3」∠)_

対応した上位機種が出てくると嬉しいのですが。

 

WPA2/WPA3 Enterpriseは使える?

仕様書に Personal の記載しかなく、実機のメニューにも Enterprise の項目がありません。

中身の hostapd は対応しているようです。6GHz帯は不明 (TP-Linkの6E対応機と同様に、6GHz帯のみ非対応のケースかも)

hostapd, wpa_supplicant は v2.10-devel が入っています。

 

VPN機能はある?

仕様のとおりで、非対応です。

openvpn-openssl が入っているようですが、設定メニューがありません。

 

エレコム WRC-BE94XS-B との違いは?

アップデート用に配布されているファームウェアイメージを調べると、両方の型番の文字列が見えました。ファイルサイズもほぼ一緒なので、基本部分は共通と思われます。

WN-7T94XRとWRC-BE94XS-Bのファームウェアイメージ

WN-7T94XRとWRC-BE94XS-Bのファームウェアイメージ

 

Wi-Fi 7対応の子機は?

例えば、Intel Wi-Fi 7 BE200を使ったこんなアダプタ ↓ が売られていますが、技適がありません。箱にも本体にも、BE200NGWのモジュールにも、技適マークが確認できませんでした。

技適付きのものが出回るまで待つか、「技適未取得機器を用いた実験等の特例制度」を使うしかないです。

もう一つ注意があって、BE200はAMDプラットフォームで動かないそうです。Windowsが正常に立ち上がらなくなることもあるとか。

 

(WN-7T94XR がもう一台欲しい)

 

現時点では以上です

 

 

 

【注意喚起】FreeRADIUSの設定は気を付けないとEAP-TLSに大穴が開く (EAP-TLSを使っていなくても)

タイトルの通りなんですが、その昔これを見つけた時はヘンな汗が噴き出ましたよ。

eapol_testを使ったEAP-TLS認証

eapol_testを使ったEAP-TLS認証

SUCCESS... (;゚∀゚)

 

自分はEAP-TLSを使わないからといっても、デフォルトで穴が開くので要注意です。

 

不具合の内容

以下の条件がすべて満たされているとき、同一CAが発行・署名したクライアント証明書を用いて、第三者によるEAP-TLS認証が成功します。無線LANに不正に接続できたりします。

  1. FreeRADIUSでPEAP, EAP-TTLSなどを使っている。
  2. Public CAから発行されたサーバ証明書を使っている (Let's EncryptでもUPKIでも、何でもよい)
  3. EAP-TLSを運用していないのに、その機能が無効になっていない (FreeRADIUSのデフォルト)。
  4. FreeRADIUSの設定ファイル mods-enabled/eap の中で、EAP-TLSを設定する
     tls { } セクションに tls = tls-common が指定されている  (デフォルト) 。
  5. クライアント証明書の属性値を検証する機能が無効になっている  (デフォルト)。

企業内で使うセキュリティがガッチリ管理された無線LANシステムでもなければ、今は端末にプリインストールされているCA証明書ストアを使うのが一般的でしょうから、結構アウトですよね。

 

検証方法 (悪用禁止)

サーバ証明書と同じパブリックCAから、クライアント証明書 (cert.pem) とその鍵 (privkey.pem) を入手しておきます。中間CA証明書をクライアント証明書の末尾にcatして、cert+.pem を作っておきます。

次のような eapol_test.conf を作成します。

network={
  ssid="piyopiyo"
  key_mgmt=WPA-EAP
  eap=TLS
  anonymous_identity="anonymous@example.com"
  client_cert="cert+.pem"
  private_key="privkey.pem"
  private_key_passwd="<鍵のパスフレーズ>"
}

レルムは自分の環境に合わせます。

privkey.pem に鍵が付いていないなら、private_key_passwd="" とします。

 

いざ!

$ eapol_test -c eapol_test.conf -s testing123

eapol_test コマンドは、wpa_supplicant パッケージなどに入っています。

SUCCESS が出たら負けです。

 

なぜこうなるのか

FreeRADIUSの設定ファイル mods-enabled/eap の中に、tls-config tls-common { } セクションがあります。証明書類をここに設定しますが、サーバ認証ばかりではなく、EAP-TLSのクライアント認証にも、同じ設定が使われるのがデフォルトです。少し下の方に EAP-TLS の設定のための tls { } セクションがあり、そこに tls = tls-common と書かれています!

一応、tls-config tls-common { } の直前に、以下のような注意書きがあります。ちゃんと読んでいますよね?

        #  Note that you should NOT use a globally known CA here!
        #  e.g. using a Verisign cert as a "known CA" means that
        #  ANYONE who has a certificate signed by them can
        #  authenticate via EAP-TLS!  This is likely not what you want.

ところで、最近のOSでは、安易にCA証明書をインストールさせない方針になっているようです。ネットで拾ってきたCA証明書を一般利用者がインストールするなんて、リスキーですからね。

というわけで、WPA2 Enterpriseを使う無線LANシステムでは、システムにプリインストールされているCA証明書ストアを使ってサーバ認証させるのが一般的になっています。上の注意書きは、この点で時代遅れで、不親切です

一方で、EAP-TLSのクライアント認証は、クライアント証明書からルートCAにたどり着けるかという certification path validation が基本になっています。パブリックCAを使うと、第三者もログインできてしまいます。

一つの対策は、クライアント証明書の中身を検証するロジックを tls { } セクションの中で有効にすることです。でも、そもそも EAP-TLS を使う気のない管理者なら、こんなところまで見ないかもしれません。また、検証といっても、実際に何を検証すれば安全なのかという問題が残ります (証明書の意味が無くない?)。

 

有効な対策

そもそも、EAP-TLS を使わないなら、tls { } セクション全体をコメントアウトすればOKです。

EAP-TLS を使うなら、クライアント認証にはプライベートCAを使うでしょう。tls-common とは別に、例えば tls-auth を別途定義すればよいでしょう。

 

おしまい

 

ps

eduroam JPでは結構前に注意喚起の文書を出したので、きちんと対策されてい……るといいなぁ。

素のEAP-TLSは安全とは言えない

プライバシー保護の点では……

 

無線LANなどの認証プロトコルとしておなじみのEAP-TLS。ID・パスワードを使うEAP-TTLSやPEAPと比べて、より優れたセキュリティを実現できるものとして、二重丸が付けられた比較表などをよく見かけます。ところがこれ、うたい文句通りに受け取ってはいけないものだったりします。

  "パスワードレスなんだ~!証明書を使うなら安全だね!" 😇

ま、まて、まて……🫠

 

以下、このようなお話です。

  • 基本形のEAP-TLSには、認証のセキュリティは高くても、証明書の中身が基地局やハブの事業者にも見えるという、プライバシー保護上の問題がある。
  • プライバシー保護の観点で、基本形のEAP-TLSは、EAP-TTLSやPEAPに劣る。
  • EAP-TLSもトンネルで保護してみよう
  • OSの対応は今後の課題

 

何が問題なのか?

素のEAP-TLSの何が問題なのかというと、ズバリ、プライバシー保護が不十分です。プライバシー保護も広義のセキュリティに入れるなら、安全とは言えなくなります。

ところでさっきから頭に「素の」と書かれているのはいったい?🤔

WPA2/WPA3 Enterpriseの無線LANでは、ID・パスワード方式のEAP-TTLSやPEAPよりも高いセキュリティが欲しいといった時に、RFC 5216の (基本的な) EAP-TLSが利用されることがあります。処理の大雑把な流れとしては、正規の認証サーバに接続しているかどうかを端末が検証するための「サーバ認証」が行われ、検証結果が正しければ、反対に端末が正規の利用者のものかを検証するための「クライアント認証」が行われるという、双方向認証になっています。

サーバ認証とクライアント認証のそれぞれで、電子証明書を用いた認証が行われます。認証のセキュリティがどうのという議論は、ここでは行いません

最近問題視されるようになったのは、プライバシー保護です。例えば、公衆無線LANの利用者がどこそこの店のアクセスポイントを使って、その後はどの店に行って、夕方にはよくこの辺に居るからおそらく自宅はこの辺……といった行動情報は、プライバシーに関わるものです。公衆無線LANの事業者には、利用者から同意なくこのような行動解析を行わないことが求められています。

しかし、中にはプライバシー保護がザルの事業者もあるかもしれない(?)ので、利用者側の対策として、端末に「MACアドレスランダム化」などの仕組みが入るようになりました。利用者認証 (または端末認証)のある無線LANでは、IDも利用者の追跡に使えるので、これを保護するための仕組みがEAP-TTLSやPEAPには用意されています。具体的には、端末と認証サーバの間にTLSトンネルを作り、基地局やハブを運用する事業者にはIDを見せないようにします。詳しくは以前の記事を見てください。

hgot07.hatenablog.com

EAP-TLSのどこで情報が漏洩するか

EAP-TTLSやPEAPと違い、(基本形の) EAP-TLSにはトンネルがありません。TLS 1.2の場合、証明書の情報が平文で通信路を流れます。クライアント証明書には利用者を識別するためのIDに相当するSubjectが含まれており、これも平文で流れます。

より具体的には、Serial Number, Issuer, SubjectなどがEAP-Messageに平文で含まれており、基地局やハブの事業者にも見えます。実際の利用者と紐づかないとしても、このように長期間に渡るユニークな固定値は、利用者端末の追跡に悪用される恐れがあります (実際は悪質な事業者とはローミングしないように運用されるのですが)。

  マジか?

なんでしたら、RADIUS proxyのところでEAP-Messageを眺めてみましょう。FreeRADIUSなら、radiusd -fxx -l stdout でデバッグメッセージを出して、EAP-Messageを簡単にダンプできます。

EAP-Messageの例

EAP-Messageの例

アカウントを発行して認証処理を行うIDプロバイダが、自身も基地局を運用する場合は、データがその事業者に閉じているので、問題は生じません。一方、ローミング環境では、データ利用に関する合意がない限り、他の事業者に実IDを秘匿することが推奨されています。

なお、TLS 1.3の0-RTT (Zero Round Trip Time)なら大丈夫という説もありますが、0-RTTはリプレイ攻撃に弱いという別の問題があります。(識者におまかせ)

[2024/2/28追記] RFC 5216 2.1.4にPrivacyの記述がありますが、オプションなので常に利用できるわけではありません。

 

トンネルで保護してみよう

証明書のやり取りをトンネルで保護すればよいのでは?
(一応、EAP-TLSTLS 1.3を使えという声もあるのですが、今後の課題)

そう、こんなこともあろうかと、使えそうな手法が用意されています。EAPを考案した人たちの洞察力には恐れ入ります。

EAP-TTLSやPEAPを使う方法があります

 

 "EAP-TTLSやPEAPって、ID・パスワードを使う方式なんでは?" 🤔

 

なんと、これも違うんですよね。EAP-TTLSやPEAPでは、端末と認証サーバの間にトンネルを掘った後に、phase2として、PAPやMSCHAPV2などの認証が行われます。実は、サーバ証明書を用いた認証も、このトンネルの中で行うことができます

参考文献はこちら ↓

learn.microsoft.com

PEAPMicrosoft独自の方式で、標準化されていないので、使うなら EAP-TTLS の方でしょう。Passpointでも、EAP-TTLS は仕様に盛り込まれていますが、PEAPはありません。

具体的には、EAP-TTLSのトンネルの中でEAP-TLSを実行する方法があります。この方法を何と呼ぶのが適切か分かりませんが、EAP-TTLS/PAP のような表記に習えば、EAP-TTLS/TLS あたりでしょうか。これだと EAP-TTLS or EAP-TLSのように誤解されそうな気もします。

 

とりあえず、やってみましょう

こんなEAP-TLS用の eapol_test.conf があったとします (wpa_supplicant.conf でも同様)。EAP-TLSでは identity= のレルムさえ合っていればよく、ユーザIDは匿名で構いません。

network={
        ssid="onin_no_LAN"
        key_mgmt=WPA-EAP
        proto=RSN
        eap=TLS
        identity="anonymous@example.com"
        domain_suffix_match="idp.example.com"
        client_cert="/etc/wpa_supplicant/XxV1ZaqB.cer"
        private_key="/etc/wpa_supplicant/XxV1ZaqB.key"
        private_key_passwd=""
}

eapol_test -c eapol_test.conf -s testing123 とかすれば、SUCCESSが返ってきます (証明書が検証に通れば!)。

上のファイルを、下のように書き換えます。

network={
        ssid="onin_no_LAN"
        key_mgmt=WPA-EAP
        proto=RSN
        eap=TTLS
        identity="anonymous@example.com"
        domain_suffix_match="idp.example.com"
        domain_suffix_match2="idp.example.com"
        phase2="autheap=TLS"
        client_cert2="/etc/wpa_supplicant/XxV1ZaqB.cer"
        private_key2="/etc/wpa_supplicant/XxV1ZaqB.key"
        private_key2_passwd=""
}

(あっ、"2" ってこういう風に使うんだ……)

これだけです!

認証サーバにFreeRADIUSを使っているなら、サーバ側の変更は不要です。

 

OSの対応状況

EAP-TTLSのトンネルでEAP-TLSが使えるかどうか、各種OSの対応状況をざっくりと調べてみた結果が以下のとおりです。

Linux, OpenWrt

wpa_supplicant ベースなら、先に書いたとおりで、対応可能です。

Windows

できました 😇

p12形式の証明書ファイルを読み込ませて、まずはEAP-TLSの設定を済ませておきます。その後、設定メニューの「既知のネットワークの管理」で「高度なWi-Fiネットワークプロパティ」を編集して、認証方法をEAP-TTLSに変更します。さらに、「認証にEAPメソッドを選択する」の中でEAP-TLSを選択します。

EAP-TTLS/TLSの設定 (Windows 11)

EAP-TTLS/TLSの設定 (Windows 11)

どのクライアント証明書を使うかの設定が見当たりませんが、SSID一覧から実際にSSIDを選択して接続しようとすると紐づける証明書を聞いてきます。

ウェブベースプロビジョニングで使うms-settings: URI スキームの対応状況は、まだ確認できていません。これが使えないと、一般の利用者に使わせるのは困難です。

macOS, iOS, iPadOS

プロファイルのリファレンスを眺めてみたのですが、該当する設定が見当たりません。

Android

Android 13の設定画面によると、EAP-TTLSのフェーズ2認証に選択できるのは、PAP, MSCHAP, MSCHAPV2, GTC だけで、TLSはありません。

ウェブベースプロビジョニングで用いられるPPS MO形式のプロファイルには、そもそも Phase2 の概念がなさそうです。

APIで設定できるかどうかは未確認です。

ChromeOS

Open Network Configuration (ONC)のドキュメントによると、Innerに指定できるのは Automatic, MD5, MSCHAP, MSCHAPv2, PAP, CHAP, GTC だけで、TLSはありません。

 

うーん_('、3」∠)_

どうしますかね、この問題……

TLS 1.3が主流になればプライバシー問題は自然と解消されるという、気の長い見方もあるようです。即効性のある対策として、EAP-TTLS/TLSは悪くないと思うのですが、対応OSが限られるのが悩みの種です。

 

おしまい

OpenWrtをTOKYO FREE Wi-Fiにつなげてみよう! (他のOpenRoamingでもOK)

[2024/1/27追記] ドメイン名の指定に間違いがあったので修正しました。

2023年3月末からOpenRoaming対応になった新生TOKYO FREE Wi-Fiに、OpenWrt箱を接続してみましょう。OpenRoamingに非対応の機器も接続できるモバイルルータが作れます。といっても、Passpointプロファイルさえ取得できれば、TOKYO FREE Wi-Fiに限りません。国内外のOpenRoaming対応のフリーWi-Fiでも使える技を紹介します。

(おやくそく) プロファイルを仕込んだルータの盗難には十分気を付けましょう。

 

OpenWrt箱を用意する - Mangoはどう?

結論から述べるとMangoではダメでした_('、3」∠)_

(急ぎたい人は次章へどうぞ)

手元にお役御免になったGL.iNet Mango (GL-MT300N-V2)があったので、最初にこれを試しました。今となってはCPUがだるいほど遅いし、2.4GHz帯専用だし、簡単にメモリ不足になるので、新規に購入することは奨めません。ちょっとどころじゃなく大きくなってしまいますが、これから買うなら、同社のSlate Plus (GL-A1300)より新しいモデルがよいでしょう。

ところで、かわいい筐体で大ヒットしたMangoですが、当初はOpenWrt 19.xベースで長いことアップグレードが止まっていました。一応、GL.iNet版ではなくOpenWrt版の21.x系ファームウェアが出てPasspoint (Hotspot 2.0)も使えるようになったのですが、公式ファームウェアが出ませんでした。ところが2023年になって突然、22.x系の公式ファームウェアが登場しました。執筆時点で Version 4.3.7 が出ているので、まずこれにアップグレードします。

手元のMangoは Version 3.105 といういにしえのファームウェアが入っていましたが、まずこれを 3.203 に上げて……と思ったら、GL.iNet ADMIN PANELのUPGRADEメニューではなぜかアップグレードできません。仕方がないので、MORE SETTINGS> AdvancedからLuCIを起動して、そちらでファームウェアを焼きます。ダウンロードできる最新版が 3.216 だったので、それを焼きました。(いきなり4.x系を焼いてもよいかも)

続いて、同様の手順で 4.3.7 を焼きます。設定内容は移行できないので、初期設定からスタートします。

ほい!

Version 4.3.7にアップグレード

Version 4.3.7にアップグレード

まって、初期状態でもうメモリがぱんぱんです;;

Version 4.3.7の中身は、OpenWrt 22.03.4でした。WPA2 Enterpriseを使うのに必要な wpa-supplicant パッケージをインストールしようにも、メモリ不足で入りません。いきなりの試合終了です

 

OpenWrt箱を用意する - Slate Plusにしてみた

[2024/1/28追記] 執筆時点の純正ファームウェア (OpenWrt 21.02ベース) では、PasspointのANQPが正常動作しないことが判明しました。OpenRoamingが採用しているRCOIマッチングの方は動きますが、基地局によっては接続できないことがありそうです (RCOIが4個以上登録された基地局)。この機種を使う場合はご了承ください。

GL.iNet Slate Plusも、Slate AXやBeryl AXと比べるともっさりしたCPUですが、モバイル用途ならまだ我慢できるかなと。たまたま()手元にあったので、今回はこれを使ってみます。

Slate Plus (左)とMango (右)

Slate Plus (左)とMango (右)

執筆時点のファームウェアはバージョン4.4.6で、OpenWrt 21.02.2ベースでした。

GL-A1300 overview

GL-A1300 overview

古いモデルと違って、最初からwpad-openssl (フル版wpad)がインストールされているので、-basic から入れ替える手間がありません。

http://192.168.8.1/cgi-bin/luci にアクセスして、LuCIの方から設定していきます。Wirelessメニューの中でWPA2/WPA3 Enterpriseのクライアント設定に進みます。radio0またはradio1のAddボタンをクリックします。

Wireless Overview

Wireless Overview

Device Configuration

Device Configuration

Device Configurationのポップアップが開くので、General Setupタブの中で、適当なESSIDを入力します。Passpointの場合、これはダミーになります。Networkはwwanを選びます。つまり、上流のネットワークにつなぐという意味です。
続いてWireless Securityタブに移動します。

Wireless Security

Wireless Security

次のようにパラメータを入力します。

  • Encryption: WPA2-EAP (strong security)
  • Cipher: "Force CCMP (AES)" にする。TKIPは使ってはいけない。
  • EAP-Method: EAP-TTLSを使うので "TTLS" を選択する。
  • Use system certificate: サーバ認証を有効にするため、必ずチェックを入れる
  • Certificate constraint (Wildcard): eap.wi2.ne.jp
    (2024/1/27:上のキャプチャ画像でSubjectの方に値が入っているのは間違いです)
  • Authentication: EAP-MSCHAPv2
  • Anonymous Identity: anonymous@tokyo.wi2.cityroam.jp
  • 802.11w Management Frame Protection: Optional

IdentityとPasswordに入力する値は、以下のようにして取得できます。

まず、(新しい方の) TOKYO FREE Wi-Fiのウェブサイトにアクセスして、規約確認の後、ソーシャルアカウントなどで認証を受けます。

TOKYO FREE Wi-Fi (OpenRoaming対応)

TOKYO FREE Wi-Fi (OpenRoaming対応)

プロファイルをダウンロードできるところまで進んだら、左上の「くわしいメニュー」を選び、プロファイルの手動設定の説明に進みます。

「プロファイルの設定」画面

「プロファイルの設定」画面

ずっと下にスクロールしていくと、「ユーザ名、パスワードを作成する」というボタンがあるので、これをクリックします。

「ユーザ名、パスワードを作成する」ボタン

「ユーザ名、パスワードを作成する」ボタン

ここで表示されたユーザ名をIdentityに、パスワードをPasswordに入力します。

Wireless Securityタブの一番下にあるSaveボタンをクリックして、Wireless Overviewに戻り、Save&Applyボタンをクリックします。

Cityroamの参加機関の基地局が近所にある場合は、ESSIDに "cityroam" を指定することで、Passpointのない802.1X認証による接続確認ができます。

※ TOKYO FREE Wi-Fiではない、他所で発行されるOpenRoamingのプロファイルも、同様に使えます。PasspointプロファイルからID・パスワードを取り出す方法はこちら ↓

hgot07.hatenablog.com

OpenWrtをPasspointクライアントとして設定する

[2024/1/29追記] 汎用に使えるように改造した hostapd.sh をGitHubで公開しました。以下の手順よりも簡単に設定できるはずです

執筆時点のOpenWrt (最新版は23.x)には、まだPasspointのクライアント機能を設定する仕組みがありません。ただし、OpenWrt 21.x以降ではPasspoint対応のwpad (hostapd, wpa-supplicant)が使われているので、一部のスクリプトを書き換えるだけで、Passpointを有効化できます。

大昔に書いた(ウソ)以下の記事を参考にして、Passpointクライアントになるように改造していきます。なお、OpenRoaming (settlement-free model)のRoaming Consortium Oranization Identifier (RCOI)が決め打ちになっているのは、ご容赦ください。

hgot07.hatenablog.com

まず、/etc/config/wireless を (お好きな) テキストエディタで開き、上で設定したものに対応する config wifi-iface ブロックを見つけます。optionが沢山並んでいますが、そこに一行だけ付け加えて、保存しておきます。

option iw_enabled '1'

まだOpenWrtに存在しないオプションなので、このままでは何も起きません。

ついでに、このファイルを別名で保存しておきます (伏線)。

# cd /etc/config
# cp wireless wireless.save

次に /lib/netifd に移動して、hostapd.sh を編集します。

# cd /lib/netifd
# cp -p hostapd.sh hostapd.sh.orig
# <お好きなエディタ> hostapd.sh

1309行目あたり (wpa_supplicant_add_network() の中)に次のような行があるので、赤字の一行を追加します。

json_get_vars eap_type identity anonymous_identity ca_cert ca_cert_usesystem

json_get_vars iw_enabled  ←これを追加

1495行目あたりから、次のように追記します。

        if [ "$key_mgmt" = "WPS" ]; then
                echo "wps_cred_processing=1" >> "$_config"
        else
if [ "$iw_enabled" = "1" ]; then
                cat >> "$_config" <<EOF
interworking=1
hs20=1
auto_interworking=1

cred={
        username="$identity"
        password="$password"
        ca_cert="/etc/ssl/certs/ca-certificates.crt"
        domain_suffix_match="$domain_suffix_match"
        roaming_consortiums="5A03BA0000"
        eap=$(echo $eap_type | tr 'a-z' 'A-Z')
        phase2="auth=$auth"
}
EOF
fi

                cat >> "$_config" <<EOF
network={
        $scan_ssid
        ssid="$ssid"
        key_mgmt=$key_mgmt
        $network_data
}
EOF
        fi
        return 0
}

ファイルを保存したら、wifiコマンドで設定を反映させます。ついでにバックアップも作っておきます。

# cp hostapd.sh hostapd.sh.save
# wifi

少し待つと…… ヽ(゚∀゚)ノ

OpenRoamingに接続された状態

OpenRoamingに接続された状態

WPA2 Enterprise用に設定したSSIDとは異なる "openroaming" というSSIDに接続されていることが分かります。That's Passpoint!

 

めでたし、めでたし……

 

コイツ、消えるぞ……

あとは自分の端末をぶら下げるSSIDを吹けばOK、楽勝!と思いきや、ここで衝撃の問題が発覚

なんと、このSlate Plusたん、リブートするとWi-Fiクライアントの設定を綺麗さっぱり忘れてしまいます。具体的には、/etc/config/wireless の中で "sta" に設定された項目が、すべて消えてしまいます。

これでは、モバイルOpenRoamingルータとして使い物にならないではないですか。

色々と探ってみたのですが、どこでこのワイプが行われているのか、まだ判りません。誰か教えて~

仕方がないので、/etc/rc.local をいじって、頭に次の二行を追加しました。(伏線回収)

cp /etc/config/wireless.save /etc/config/wireless
wifi

 

今度こそ、めでたし、めでたし! (だといいなぁ)

 

 

 

Passpointプロファイルのばらしかた (分析方法)

OpenRoamingなどで使われているPasspointは、WPA2/WPA3 Enterpriseをベースにして、さらに高度な機能 (802.11u) が盛り込まれたものです。事前共通鍵 (PSK, Pre-Shared Key) を使うWPA2/WPA3 Personalと違って、Enterpriseでは、ID/パスワードやクライアント証明書に加えて、認証方式やサーバ認証のための証明書、ドメイン名など、端末に設定する項目が多くなっています。Passpointの端末設定には、さらに多くの設定項目が必要です。このため、これらの情報を手入力するのが難しいので、端末設定には「Passpointプロファイル」と呼ばれるデータを使ったり、専用の設定アプリを使ったりするのが一般的です。

例えば、OpenRoamingに対応した (新しい) TOKYO FREE Wi-Fiでは、Passpointプロファイルと、アプリの、いずれかを用いて端末の設定が可能になっています。

ところで、Passpointプロファイルの中身は、一体どうなっているのでしょうか。この記事では、Passpointプロファイルのばらしかたを紹介します。

 

Passpointプロファイルをファイルに落とす

最近のOSには、ウェブサイトからPasspointプロファイルをダウンロードして、Wi-Fi周りの設定を容易に行うことのできる仕組みが組み込まれています。このようなWi-Fi設定方法は、web-based provisioning と呼ばれています。

Passpointプロファイルの中身を覗くために、まずファイルに落としたいのですが、普通にウェブサイトで設定ボタンをタップするとWi-Fi設定に自動的に流し込まれてしまいます。ファイルとしてダウンロードする隙がありません。

また、OS自動検出機能がウェブサイトに組み込まれていることもあり、例えばWindowsAndroid用のプロファイルを取得しようにも、User-Agent を偽装しなければいけません。要するに、面倒……

Chromeブラウザを使うと、各種OS用のプロファイルを手っ取り早くダウンロードすることができます。WindowsChromeなら、F12キーを押すことで、各種OSのエミュレーションができるモードに入ります。

ChromeでF12を押したところ

ChromeでF12を押したところ

Dimensionsの設定でOSを選びます。あとは、Passpointプロファイルを配布しているウェブサイトにアクセスして、所定の操作をするだけです。Wi-Fi設定などのメニューが自動的に開くことがなく、プロファイルがファイルとしてダウンロードできます。

 

執筆時点で、プロファイルの形式はOSごとにまちまちで、統一されていません。唯一、Androidが使用している PPS-MO (Per-Provider Subscription - Mobile Object) 形式は Wi-Fi Alliance によって制定された汎用フォーマットですが、AppleMicrosoftはこれを採用していません。

 

Android用Passpointプロファイル

Wi-Fi Alliance が制定した、PPS-MO 形式が用いられています。Android 11以降で、Wireless Broadband Alliance による拡張属性にも対応しています。

プロファイルの形式は、この辺 ↓ を見れば分かります。

プロファイルをテキストファイルとして覗いてみると、Base64っぽい文字列が出てきます。

Passpointプロファイルの中身 (Android)

Passpointプロファイルの中身 (Android)

マルチパートMIMEエンコードされているので、順番にデコードしていけばよいです。

Linuxなら、

$ base64 -d  passpoint.conf > profile.txt

Base64のデコードができます。

続いて、テキストエディタなどを使って、各パートに切り分けます。

最初のパートはXML形式で、ここに様々なパラメータが埋め込まれています。

二番目のパートは、これまたBase64っぽい内容なので、デコードします。サーバ認証用のCA証明書が含まれていることが確認できると思います。

$ base64 -d part2.txt > cacert.pem
$ openssl x509 -text -in cacert.pem | less

EAP-TTLSならば、この2パートだけです。EAP-TLSの場合は、クライアント認証のためのクライアント証明書がこの後に続きます。

 

Apple用Passpointプロファイル

macOS/iOS/iPadOS共通で、mobileconfig形式のプロファイルが使われています。XMLで記述されています。自前のプロファイルを作りたいなら、Apple Configuratorアプリでも作ることができます。

プロファイルの形式は、この文書 ↓ を見れば分かります。

Passpointプロファイルは、署名付きと署名無しの二種類があります。テキストファイルとして覗いてみて、先頭が文字化けしているように見えたら、署名付きです。

以下のようにして、署名を削除できます。

$ openssl smime -verify -noverify -inform der -in passpoint.mobileconfig -out nosign.mobileconfig

 

Windows用Passpointプロファイル

Windows 10以降で、ms-settings: URIスキームによるWi-Fi設定が可能になっています。プロファイルはXMLで記述されており、これにXML署名が付いています。署名は必須で、XMLデータの末尾 (最終タグの手前) に埋め込まれています。プロファイルを覗くだけなら単に無視すればよいです。

プロファイルの形式について、あまりまとまった文書がありません。この辺 ↓ を見て頑張って解析します。

 

Passpointプロファイルの作り方

自前のプロファイルを作るのは、色々とつまづく点が多くて、結構面倒です。プロファイルの作成を容易にするためのツールを作りました (結構前の話)。試してみたい人はどうぞ。Passpointのパラメータさえ知っていれば、様々なOSのプロファイルを作成して、ウェブサイトで配布できるようになります。

github.com

おしまい

 

Passpointプロファイルのことが分かったら、次はアクセスポイントで遊んでみたくなりませんか? (・∀・)

booth.pm

GL.iNetのOpenWrt箱をPoEで動かす

GL.iNetは様々なOpenWrtベースの無線ルータを扱っている会社です。OpenWrt 21.x以降ではPasspointも動き、WireGuardなどの各種VPNが容易に使えるということで、モバイルCityroam基地局 (eduroam, OpenRoaming込み)として、同社の様々なモデルが重宝しています。

モバイルに限らず、最近よく聞くようになった「マネージドWi-Fi」の基地局としても、小規模な店舗に転がす用には、便利に使えるのではないかと思います。

小柄なルータで、基地局VPNの機能がワンボックスで済むところはとても良いのですが、残念ながらPoE (Power over Ethernet)に対応していません。PoEが使えるなら、近くにコンセントのない場所でも使いやすいのに……

方法を探してみると、ありました、PoEスプリッターという製品が。品揃えも充実しています。以前に、MikroTik hAP acを駆動するのにDC12Vプラグ付きのものを使ったことがあります。今回は GL.iNet Beryl AX (GL-MT3000) や Slate AX (GL-AXT1800) を使いたかったので、USB Type Cのスプリッターを試してみました。これです。

 

ANVISIONからは、似た製品が各種出ています。速度でいうと、100Mbps止まりのものと、1000Mbps対応のものがあるので、うっかり安い方に飛びつかないように、仕様をよく確認する必要があります。あとは電源/USBプラグの違いです。

Beryl AXのWAN端子は2.5GbEなので、1000Mbpsまで使える方のモデルを選びました。実際に取り付けてみると、こんな感じです。

Beryl AXのPoE駆動 (その1)

Beryl AXのPoE駆動 (その1)

Beryl AXのPoE駆動 (その2)

Beryl AXのPoE駆動 (その2)

まって❤ Beryl AXには5V 3Aが必要ではないの?

えぇ、このスプリッターの定格は5V 2.4Aなので、ちょっと足りないです。しかし、Beryl AXの仕様表には消費電力8W以下と書かれています。これまで何度も2.4AのACアダプタで普通に使えたので、大丈夫ではないでしょうか。 (現場猫画像略)

さらに、良いニュースと悪いニュースがあります。まずは悪い方から。

2.5GbEに対応したPoEスプリッターがないか探してみたのですが、見つかりませんでした!

監視カメラなどの用途が多いせいか、1000Mbps止まりなんですよね……

良い方はというと、
なぜか2.5Gbpsでリンクアップする! (゚∀゚)

2.5Gbpsでリンクアップ

2.5Gbpsでリンクアップ

おそらく、イーサネットの接続はヘンなチップなど介さないでスルーなのでしょう。

過度な期待はしないでください。

 

おしまい