hgot07 Hotspot Blog

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

FreeRADIUSでLet's Encryptの証明書を使う

WPA2/WPA3 Enterpriseの無線LANで、ID/パスワード認証を使うときは、サーバ認証を行うことが必須または強く推奨されています。

具体的には、EAP-TTLSを使う場合はサーバ認証が必須で、PEAPでもMSCHAPv2のセキュリティが弱いのでサーバ認証が強く推奨されています。詳しくは以前の記事をご覧ください。

hgot07.hatenablog.com

※ タイトルにある組み合わせ、それなりに長いこと運用していますが、もし動かなくなったらごめんなさい。

 

サーバ認証で使うべき証明書

EAP-TTLSやPEAPでは、基地局に端末を接続しようとする際に、まずサーバ認証を行って、これから接続しようとする基地局が正規のものかを確認します。基地局そのものの真贋を確認するのは無理なので、実際は、基地局が正しい認証サーバ (AAAサーバ)につながっているかどうかを確認します。ここで、公開鍵基盤 (PKI, 必ずしも一般公開とは限らない) の電子証明書が使われます。利用者認証が行われるのは、サーバ認証に成功した後です。

利用者認証、というか正確には端末認証を実施するEAP-TLSでは、ID/パスワードの代わりにクライアント証明書が使われます。これは、サーバ認証とは異なるものです。

「サーバ認証用の証明書を取得してRADIUSサーバに導入しろと言われても、どうすればいいの?」
「証明書は買わないといけないの?」

FreeRADIUSの場合、インストールすると自動的に /etc/raddb/certs の下にデモ用の証明書が作成されます。サーバ認証関係の設定は /etc/raddb/mods-available/eap というファイルに書かれています。初期状態ではデモ証明書が使われます。RADIUS proxyとして動作させるだけならこのままでもよいのですが、認証を行う RADIUS IdP として使うなら、デモ証明書を使い続けてはいけません (そもそも60日で期限切れになる)。

certs ディレクトリの中にある設定ファイル ca.cnf と server.cnf を自分のサーバに合うように修正して、証明書を作り直せば、プライベートなPKIとして運用することが可能です。

Enterpriseな無線LANで、できるだけセキュリティを高めたいなら、プライベートCAで発行した証明書を使うのがよいでしょう。ただし、個々の端末にCA証明書をインストールする手間があります。企業などで MDM (Mobile Device Management) を使うならよいのですが、利用者個人が無線LANの接続設定を行う企業やキャンパスの無線LANでは、採用しにくいかもしれません。端末にCA証明書を導入する操作は、セキュリティリスクもあるので、個人に任せるのは少し不安です。

グローバルなパブリックCAを使うのはどうでしょう?

端末には著名なCA証明書がプリインストールされているので、CA証明書を追加でインストールする手間 (とリスク) がなくなります。ただし、同じCAを使う第三者RADIUSサーバを正規のものと認識しては危険なので、ドメイン名を確実に確認する必要があります。つまり、サーバ証明書の発行の際に、ドメイン名と所有者が紐づけられているところに、信頼が生じるという仕組みです。

 

Let's Encryptの証明書でも大丈夫か

Let's Encryptでもドメイン名のチェックはできているので、Let's Encryptで取得したサーバ証明書RADIUSで使っても、大丈夫でしょう。Android無線LANの設定をするときに、CA証明書で「システム証明書を使用」を選び、ドメインを入力するだけという、お手軽設定になります。

サーバ認証の設定

サーバ認証の設定

FreeRADIUSの設定方法

Let's Encryptサーバ証明書の取得は、ウェブサーバ向けの設定ガイドが多数存在するので、そちらをご覧ください。certbotが少しずつ変化しているので、できるだけ新しい記事を探すとよいです。

FreeRADIUSですが、現在の最新版 3.2.0 と、一つ前の 3.0.25 で確認しています。3.0.x 系には、TLS接続が不安定になる致命的な不具合があります。3.2.0 以上を使うべきです。

サーバ証明書の設定は mods-enabled/eap の、tls-config tls-common セクションにあります。

private_key_password = は、たぶん空でよいはず (Let's Encrypt次第)。

private_key_file = には、privkey.pem を指定します。

certificate_file = には、cert.pem を指定します。

ca_file = には、chain.pem を指定……、アレ?

We've got a problem!

Thu Jul  7 13:55:35 2022 : Auth: (31) Login incorrect (eap_peap: (TLS) Alert read:fatal:certificate expired): ...

ど、どうして……

当エントリを起こそうと思い立った理由がこれです。

chain.pem には、CA証明書と中間CA証明書のチェーンが含まれているのが普通です。執筆時点で、chain.pem には2つの証明書が含まれていて、先頭から、中間CA証明書 (CN= R3)、ルートCA証明書らしきもの (CN= ISRG Root X1) です。後者が曲者で、2021年9月に破棄された古い証明書 (CN= DST Root CA X3) で署名されていました

Apache HTTP Serverに仕込んで、ブラウザで証明書の情報を見ると、ISRG Root X1 が新しく自己署名証明書になっているのが分かります。

というわけで、chain.pem の先頭にある R3 の証明書だけ残して、後半を新しい方に差し替え、これを ca_file に設定します

今度は無事に動きました (゚∀゚)

[2024/4/8修正] ……だったのですが、その後にeduroamでも色々と知見が共有されるようになって、中間CA証明書はサーバ証明書と組み合わせるべきという話になりました。具体的には、以下のようにします。

 

private_key_password = "" つまり空にする。

private_key_file = には、privkey.pem を指定する。

certificate_file = には、cert.pem と中間CA証明書(ISRG Root X1で署名されたR3)を連結したものを指定する。

ca_file = には、ISRG Root X1 だけを指定する。

 

中間CA証明書が複数になるケースも考えたら、サーバ証明書と紐づく中間CA証明書を一緒にクライアントに送るのは理にかなっています。

 

めでたし めでたし

 

余談

EAP-TLSでは、サーバ認証とクライアント認証で、異なるPKIを使うことができます。というか、クライアント認証にパブリックCAを用いるのは、セキュリティ的に問題があります。mods-enabled/eap 内に(ちょっと不親切な)コメントがあります。

従って、選択肢は二つ。

運用コスト次第ですが、後者も妥協点として悪くないようです (とある識者の技術指導 より)。

 

certbot 1.6以上には --preferred-chain "ISRG Root X1" なるオプションがあるそうで、これでもいけるかな?

5G-USBドングル APAL Tributo 5G を試す

[2023/3/22追記] 続編も書いたのでどうぞ。

 

ひょんなことからNICT Beyond 5Gの委託研究に関わることになりました。自分はWi-Fiローミング専門なのですが、セルラーWi-Fiの連携を図るという課題で、セルラー側を担当している共同研究者に感化されて(笑)、5Gでも遊んでみようかなという気になってきました。

可搬型Cityroam基地局を作るのに、上流回線がLTEでは物足りないので、5Gを試してみたいという気持ちもありました。

検証機として借りたのがこちら。

\ ババーン! /

APAL Tributo 5G USB dongle

APAL Tributo 5G USB dongle

ちゃんと技適取得済みですが、一般向けの販売チャネルはまだまだのようです。技適があるからといって、技適マークのないものを入手して国内で使うのは違法ですよ!ちゃんと技適対応の業者から入手しましょう。

手元に5G対応のSIMがなかったので、今回、ONEモバイルONEに5Gオプションを申し込んで、これで試してみました。サマリはだいたいこんな感じです。

  • WindowsでMBIMモードで動く。
  • SIMロックフリー (今回OCNモバイルONE (5G)とIIJモバイルサービス/タイプI (LTE)のドコモ回線のみで確認)
  • LTEドングルの倍ぐらいの容積がある (仕方ない)。ファン付き。
  • 定格5V 3AなのでUSB Type-C接続推奨。
  • 5Gは、ドングルの特性というより、環境の影響を受けやすいので評価できていない。

 

どんな製品か

執筆時点で、5G対応かつ技適対応のドングルはまだこれ一択といった感じです。

詳しい製品紹介は本家でどうぞ。台湾の製品です。

www.apaltec.com

サイズ感、動作音、電源など

LTE-USBドングルの倍ぐらいの大きさで、USBコネクタで支えるのが無理なサイズ。短いUSB Type-Cのケーブルが付属しています。中身は Qualcomm Snapdragon X55。

Tributo 5G

Tributo 5G

付属ケーブルによる接続

付属ケーブルによる接続

冷却ファンが入っています。LTEで動作中は回らないようですが、5Gを掴んでしばらくすると軽くミーと鳴き始めます。軽量ノートPCの冷却ファンはシャーと結構大きな音がするものが多いですが、それと比べればずっとかわいいもので、会議場で顰蹙を買うことはなさそうです。

一旦ファンが動き始めると、低負荷になっても止まることはないみたいです。

電源の定格が5V 3Aと、大喰らいですが、ちんちんに熱くなるといったことはなさそう (要追加調査)。電源容量には気を付けてと、メーカーより注意あり。

 

ドングルの動作モード

WindowsではMBIMモードで動きます。ハードウェア自体はRNDISにも対応しているらしいのですが、一般利用者が切り替える手段は提供されていません。macOSでの動作は今回確認していません。

MBIMモードで動作するということで、なんと嬉しいことに、無線LANのSIM認証が使えます!(・∀・)  もちろんSIM認証に対応したキャリアとWPA2 Enterpriseのローミング対応基地局でないと使えませんが。

もしRNDIS対応ならMikroTik hAP acでも使えるのですが、残念ながらhAP acにTributo 5Gを挿しても反応無しでした_('、3」∠)_

 

5Gで使ってみる

ドコモのサービスエリアマップを眺めてみたら、自宅はエリアの縁にあり、微妙でした。室内では、ごくたまに5G表示になるものの、すぐにLTEに落ちてしまうので、ぎりぎりアウト_('、3」∠)_

おや、青葉山駅の周辺にポツンと5Gエリアが!(゚∀゚)

5Gエリア 青葉山駅

5Gエリア 青葉山駅

残念ながら入居している建物はエリア外で、ピクリとも動きませんでした。駐車場に出たら、おや、5G表示が…… (初体験)

Pixel 6で5G

Pixel 6で5G

Pixel 6でSpeedtest

Pixel 6でSpeedtest

深夜ですが、Pixel 6では190Mbps出ていました。

Tributo 5Gは少し感度が低いのか、アンテナピクトが1, 2本しか立たない状態でした。

Windows 10で5G接続

Windows 10で5G接続

とりあえず、いま5Gで大人気のSpeedtestで測ってみましょう。

まぁ、LTEより速いのですが、80~120Mbps台と安定しません。エリア外なので仕方ないです

Speedtest (エリア外)

Speedtest (エリア外)

気を取り直して、エリアど真ん中に移動してみます。あれかな? (基地局ソムリエさん、よろしく)

5G基地局?

5G基地局

5G基地局らしきもの

5G基地局らしきもの

この場所ではアンテナピクトが3本立ちましたが、速度はまだ120Mbps台。お前の本気はこんなものではないはずだ。

どうやら広場方向を向いているようなので、そちらに移動してみます。

5Gテストエリア()

5Gテストエリア()

青葉山駅前

青葉山駅

ぉ……(・∀・)

 

アンテナピクト

アンテナピクト

Speedtest結果

Speedtest結果

物足りない感じの結果を目の当たりにした顔をしながら、一旦テストは終了です。

これ、おそらくドングルではなくて、無線環境か回線の方が頭打ちになっている気がします (要追加調査)。

LTEよりは確実に速いので、5Gエリアのど真ん中に住んでいる(?)人で、Windowsに5Gを追加したい人には、良い製品でしょう。半導体不足によりLTE-USBドングルが手に入りにくくなっているので、その代わりにもなりそうです。

自分の委託研究では、Local 5Gの基地局も建てる予定です。そちらの環境なら、ずっと詳しいデータが取得できると思います。

 

おしまい

 

[2023/3/3追記] Compalの中の方から、Amazonで扱い始めたという情報を得ました。販売元が Palcom International Corporation (Compalの製品販売子会社) なことを確認してください。技適シールも貼られていると聞いています (私自身は未確認)

[2023/3/20追記] 試しにAmazonで買ってみたら、ちゃんと技適シールが貼られたものが届きました (ただし自己責任でどうぞ)。なお、日本向けは専用ラインで製造しているとかで、台湾で買っても日本の技適シールはないそうです。

Amazonで購入したTributo 5G

Amazonで購入したTributo 5G



 

SolarisでもLinuxでも動くランダム文字列生成

mkpasswdがどこにでもあると思うなよ!

 

RADIUSのshared secretやら()、初期パスワードやら、ランダムな文字列が欲しいことがまれによくあります。キーボードからグチャグチャっとやると一様性に乏しいので、ここはきちんと機械的に作りたいものです。

そんなもの、コマンド一発でありそうなものですが……?

とあるサイト「mkpasswdコマンドを引数なしで実行すると、9文字のパスワードが生成される」

いや、それ古いコマンドだし、同名で用途の違うものがあるから!

ウェブをあさってみると、こんな感じ↓のワンライナーがあちこちで紹介されています。

  $ cat /dev/urandom | tr -dc "[:alnum:]" | fold -w 12 | head -n 1

この例では、英数字の12文字からなるランダム文字列をひとつ作成しています。

何をやっているかというと、乱数ソースから英数字だけの長~~~い文字列を生成して、12文字ごとに折って(改行を入れて)、一行だけ出力して終了。

これは使える!(゚∀゚) ……と、早速LinuxからSolarisに移って実行してみると……

  $ cat /dev/urandom | tr -dc "[:alnum:]" | fold -w 12 | head -n 1
  tr: Input file error: Illegal byte sequence

がっくし_('、3」∠)_  わけがわからないよ。

 

Solarisのtrでも動くランダム文字列生成

調べてみると、SolarismacOSでも同様の症状らしい。

原因は、範囲外の文字コードがtrに入力されたため。余計なことしやがって……

ロケールを変更すると、きちんと動くようになります。ついでに整理して短くしましょう。

  $ LC_ALL=C tr -dc "[:alnum:]" </dev/urandom | fold -w 12 | head -1
  4MCbSob7U0AD

うまくできました。Linuxでもこのままで使えます。

 

16進数のランダム値を作成してみる

とあるスクリプトで16進数のランダム値が必要になったので、改造してみます。

  $ LC_ALL=C tr -dc "[:xdigit:]" </dev/urandom | fold -w 16 | head -1
  7a82ECca7C9D0b87

チガウソウジャナイ...

  $ LC_ALL=C tr -dc "[0-9][A-F]" </dev/urandom | fold -w 16 | head -1
  D36485138D802806

うまくいったもよう。

 

ではLinuxの方で……、

  $ LC_ALL=C tr -dc "[0-9][A-F]" </dev/urandom | fold -w 16 | head -1
  [ED51]]C12FFEEC9

おうふ_('、3」∠)_ 

 

Linuxでは、こうすることで、期待した文字列が得られました。

  $  LC_ALL=C tr -dc "0-9A-F" </dev/urandom | fold -w 16 | head -1
  9085421AB6710C4E

ところが、これをSolarisで実行すると、

  $  LC_ALL=C tr -dc "0-9A-F" </dev/urandom | fold -w 16 | head -1
  0-FAA9F9FF-9-9--

と、にゃーんなことに。

 

調べてみると、System VとGNUでtrの仕様が大きく異なっていて、System Vでは範囲を [0-9] のように書くのに、GNU trではダメで、0-9 と書かないといけないとのこと。逆も真。なんてこったい。

 

LinuxSolarisの両方で動くように書くと、こんな感じでしょうか。

  $  LC_ALL=C tr -dc "[:digit:]ABCDEF" </dev/urandom | fold -w 16 | head -1

 

もっと良い手があるのかもしれませんが、とりあえず。

 

PS
つくづく、自分は地雷を踏むのがトクイです💥
ポータビリティのあるコードを書こうとすると、自然とこうなりますよ。

 

おわり

Windowsで5GのSIMが圏外になる問題 (解決済)

5Gはまだエリアが狭いし、モバイルはLTEの速度で満足しているので、もうしばらく様子見のつもりでした。しかし、Beyond 5Gの委託研究に取り組むことになったので、少しずつ外堀が……。

 

普段はセルラーではなくWi-Fiばかりいじっている自分ですが、可搬型Cityroam基地局を作って転がしていたりすると、上流回線をセルラーにしたいことがたまにあります。LTEドングルでは15Mbps程度なので、5Gを試してみたいなということで、こんなものを手に入れました。

 

(・∀・)っ APAL Tributo 5G

APAL Tributo 5G USB dongle

APAL Tributo 5G USB dongle

これのレビューは後日にするとして、今回はWindowsではまった話です。圏外から抜け出せない……_(゚。3」∠)_

 

5GのSIMを調達する

モバイル機器用にOCNモバイルONEのSIMカードを持っていたのですが、5Gオプションが無料で付けられることを知って、まずはこれで試してみることにしました。

ウェブで申請して、申し込み完了通知はすぐメールで届いたのですが、いつ開通するのかが不明。数日経っても音沙汰なし。ん?

Pixel 6に挿してみたら、あれ、5G表示が出ている!

どれぐらいの時間や日数で切り替わるのか、教えてくださいよ、NTTコミュニケーションズさん。

 

5GドングルでもノートPCでも「圏外」だと!?

上記のドングルに挿してWindows 10と11のPCで試してみたのですが、DOCOMOとして自動認識されるものの、いつまで経っても「圏外」表示のままです。LTEモデム内蔵のノートPCにSIMカードを挿してみても、やはり圏外。ノートPCはIIJSIMカード (ドコモ回線)で使えていたのになぁ。

圏外表示

圏外表示

自動設定されたAPN

自動設定されたAPN

設定を見ると、既定のAPNが適用済みになっています。ただ、「LTE用のAPN: 利用できません」が気になる。

 

ちなみに、LTEまでのIIJのSIMでは、自動設定ではHSDPA、すなわち3G接続に張り付く問題がありました。

 

「APNの種類」が曲者

手動で設定を入れてみましたが、OCNのSIMは「圏外」表示のまま、IIJのSIMはHSDPAに張り付いたままで、謎は深まるばかり。スマホではLTEがバンバンつながる場所なのに、一向にLTEを掴まない。

そうこうしているうちに、やっと見つけました!

APNを追加する際に、下の方にある「APNの種類」の項目、選択肢を見てもよく分からないのでそのままにしていたのがダメでした。ここを標準の「インターネット」から「インターネットおよびアタッチ」にしないとLTEの設定が入りません。

APNの手動追加

APNの手動追加

おい、「アタッチ」って何よ?

APNの手動追加結果

APNの手動追加結果

LTEアタッチ」……だと?

技術に明るくないと、「アタッチ」が何か分からないじゃないですか。しかも選択肢で「LTE」が省略されている罠。

Windowsはこういったところが本当にだめ! (他にも似たような紛らわしさが多数)

スマホなら、オプションの選択肢が4Gとか5Gとかいう表示になっているので、分かりやすいです。

 

無事に接続完了

以上で「圏外」問題とHSDPA張り付き問題は解消して、無事にLTEで接続できるようになりました。

LTEに接続済み

LTEに接続済み

5Gにも接続

5Gにも接続

ヽ(゚∀゚)ノ

一瞬でしたが、Tributo 5Gドングルで5Gを掴みました!

残念ながら、5Gの電波が惜しいところで届かない部屋なので、すぐにLTEに落ちてしまいましたが。

さて、今回、「圏外」表示に振り回されて、OCNのSIMカードの不良まで疑ってしまいました。原因として考えられるのは、5G対応のSIMカードが3G非対応なことです。これと、Windowsの分かりにくいAPN設定が組み合わさって、以下の状況になったと考えられます。

  • Windows 10も11も、「自動設定できますよ~」という顔をしながら、半端にしか設定してくれない。
  • APNの手動追加を試みたものの、LTEアタッチを選び損ねたので、モデムには3Gの設定しか入らない。
  • 5GのSIMカードが3Gに非対応で、これをWindowsは「圏外」と表示する。

Windowsの設定メニューと表示が分かりにくいせいで、随分時間を無駄にしました。Windowsの開発者は、いったいいつになったら、ふつうの人々が使えるようなUIにしてくれるのでしょうか?

 

おしまい

 

ちなみに、5Gオプション付きの OCNモバイルONE のSIMカードピクセラLTEドングル PIX-MT110 に挿した場合、問題なくLTEで接続されました。

このドングルは、半導体不足により、残念ながら終売になってしまいましたが。

 

30WソーラーパネルENEPORTAでMikroTik hAP acを起動できるか

どこまで安定して使えるか未確認で進行形

訳あって電力契約なしの建物に無線LAN基地局を立ててみたくなったのですが、ソーラーパネルが使えるかどうか気になったというのが始まりです。

Cityroamのサイトを増やそうという魂胆なので、Passpointが使えて、リモート管理できる基地局ということで、いつものMikroTik hAP acです。ネット回線もないので、LTEドングルを挿してバックホールにするつもり。

あと、夜間も電波を吹きたいので、日中の余剰電力を貯めておけそうなバッテリも欲しい。かといって、あまり大きいパネルやバッテリは置きたくない。

 

というわけで、ヨドバシとネットで色々と眺めてみたものの、普及クラスと思われるポータブルバッテリは軒並み売り切れになっていました。部品不足のせいか、それとも3月の大地震の後だったせいか……。

ヨドバシで、ちょうど在庫があって、電力的にも手頃なものを見つけたので、速攻で購入してきました。これです。

EP-30SPの定格は18V/30W。hAP acのDC入力は11~57Vと幅広く、最大17Wで実際はずっと低いので、このパネルで賄えそうな予感。

ソーラーパネルの不安定な電源でhAP acのpower on resetがきちんとかかるかどうか不安ですが、とりあえずエイヤッと直結してみます。

EP-30SPとhAP ac

EP-30SPとhAP ac

起動したhAP ac

起動したhAP ac

ピッ (゚∀゚)

仙台の春先の日差しで、うまく起動できたみたいです。14:30頃でしたかねぇ。

 

さて、実際に使おうとしている建物は、北東の窓しかないので、北窓明かりしか期待できません。日陰だとどんな感じでしょうか?

日陰テスト

日陰テスト

うんともすんとも言いません。LEDすら点きません……_('、3」∠)_

部分的に陰にした状態

部分的に陰にした状態

これぐらい日に当ててやっとLEDが付いたものの、プツプツと起動に失敗している音が。あぶない。

明かり取りの窓でテスト

明かり取りの窓でテスト

明かり取りの窓でも、やはり起動しません。

開放電圧

開放電圧

(テスターを縦に置くんじゃない!)

開放電圧では16Vあるので、暗い場所で負荷がかかると電圧降下があるのでしょう。

ポータブル電源

ポータブル電源

ポータブル電源EP-100Rをつないでみると、おや?

一応、ちょろちょろと充電はできそうです。しかし、昇圧したところで、hAP acが動かせるだけの電力は無理そう。

太陽光の下では20V

太陽光の下では20V

参考までに、太陽光の下では開放電圧20Vぐらい出ていました。

 

というわけで、予定していた建物での運用は無理。残念!

直射日光の当たる窓ならば、使い物になりそうです。ただ、バッテリが干上がるような天候だった場合、EP-100Rの電源が落ちてしまうので、電源ボタンを押す人がいない遠隔地で無人運用するのは難しそうです。10%溜まったら自動で電源ONとかできるとよいのですが。

 

おわり

 

 

Configuring Hotspot 2.0 (Passpoint) on OpenWrt

This document provides a brief explanation of configuring Hotspot 2.0 (Passpoint, more officially) on OpenWrt to make an Access Point providing Passpoint services. Tests have been done using some GL.iNet devices including Mango, Slate, and Beryl (both int./ext. PHYs).

If you are interested in OpenRoaming, please see also:

hgot07.hatenablog.com

 

GL.iNet Beryl + NETGEAR A6210 under Hotspot 2.0 testing

GL.iNet Beryl + NETGEAR A6210 under Hotspot 2.0 testing

 

Requirements

  • OpenWrt compatible device with Passpoint-capable wireless device (PHY).
  • OpenWrt 21.02, or newer, including wpad (hostapd) built with hs20 option.
  • Full version of iw package in OpenWrt.
  • 802.1x infrastructure (RADIUS server).

 

Overview

wpad, a hostapd variant, needs to be built with hs20 option. To check whether the program is capable of Hotspot 2.0, please try:

  # strings /usr/sbin/wpad | grep hs20

If nothing shows up, that wpad isn't capable of Hotspot 2.0.

The default package installed is normally wpad-basic (-wolfssl), which doesn't have Hotspot 2.0 support. You have to remove wpad-basic and install a full version of wpad, such as wpad-openssl.

In addition, the iw package also needs to be replaced with iw-full package. Please be careful not to have wireless drivers also removed. If they are deleted, you have to re-install them.
[2024/3/22] Deleted.
Warning: GL-MT3000 users should not try changing the iw package. Removing it would break Wi-Fi driver. If you cannot see the chip name in the LuCI's wireless menu, the system is broken and you need to burn the firmware again.

Unlike the hostapd configuration on a Linux box, hostapd.conf cannot be edited manually. UCI (Unified Configuration Interface) is used to auto-generate the hostapd.conf on OpenWrt.

More specifically, a shell script "/lib/netifd/hostapd.sh" will generate "/var/run/hostapd-phyX.conf" based on the wireless configuration file "/etc/config/wireless" in the UCI.

 

Hotspot 2.0 configuration

We assume that an SSID has already been configured with WPA2/3 Enterprise (802.1x). Please refer to other documents for this configuration.

Hotspot 2.0 can be enabled by adding some option and list lines to the "config wifi-iface 'wifinetX'" section. An example is shown below. Some lines need to be fixed according to your own service.

Example:

        option iw_enabled '1'
        option iw_interworking '1'
        option iw_access_network_type '3'
        option iw_internet '1'
        option iw_disable_dgaf '1'
        option iw_asra '0'
        option iw_esr '0'
        option iw_uesa '0'
        option iw_venue_group '2'
        option iw_venue_type '8'
        option iw_hessid '00:00:00:01:02:03'
        list iw_roaming_consortium 'xxyyzz0000'
        list iw_nai_realm '0,example.com,13[5:6],21[2:4][5:7]'
        list iw_nai_realm '0,example.org,13[5:6],21[2:4][5:7]'
        list iw_venue_name 'eng:somePublicSpace'
        list iw_venue_url '1:https://www.example.com/info-eng'
        option iw_network_auth_type '00'
        option iw_ipaddr_type_availability '0c'
        list iw_domain_name 'example.com'
        option hs20 '1'
        option hs20_oper_friendly_name 'eng:YourFriendPasspoint'
        option hs20_operating_class '517C'

 

As you can easily guess, "option" is used to specify only one option, while "list" is used to list multiple options. In the example above, two NAI realms, example.com and example.org, are configured with EAP methods "EAP-TLS with certificate" and "EAP-TTLS/MSCHAPv2 with username/password."

The parameter names and their contents can be found in the template of the hostapd configuration file. Please look into the "/lib/netifd/hostapd.sh" script to see which options are actually available.

 

Testing the Hotspot 2.0 functionality

To make the configuration effective,

  # wifi

To see whether the SSID becomes available,

  # iwinfo

And, you should see "Hotspot 2.0" message or a description embedded in the Passpoint profile on a client device.

The following command shows you whether Passpoint is supported by the Wi-Fi device on Windows 10/11. If "ANQP Service Information Discovery" is "Supported," Passpoint is supposed to work.

  > netsh wlan show wirelesscapabilities

 

Troubleshooting

If wpad won't come up and the SSID disappears after setting "option iw_enabled '1'", there may be some wrong or missing parameters in the configuration.

Support of Hotspot 2.0 seems still in flux as of writing. A known problem is that UCI leaves iw_venue_name and iw_venue_url to blank and wpad fails to start. Please check "/var/run/hostapd-phyX.conf" and see whether the parameters are passed correctly.

 

 

 

 

 

UniFi Network ApplicationをDockerコンテナで動かす

Ubiquiti無線LAN基地局を使うには、基地局と同じサブネットの上にコントローラが要ります。前回、VirtualBox上にUbuntu Serverの仮想マシン(VM)を作って、そこでコントローラを動かしてみました。

hgot07.hatenablog.com

VirtualBoxでも使えそうですが、UbuntuのOSインストールやら管理やらが必要になるので、その辺がちょっと面倒な感じです。

もしかしてopenSUSE上のDockerでもUbuntuが使えたりしない?
その上でUniFi Network Applicationも使えたりしない?

 

結論

  • DockerコンテナのUbuntuでは、UniFi Network Applicationのインストールがうまくいかず、そのままでは走らない。
  • UniFi Network Application のDockerイメージが配布されているので、それを使うのが簡単。

以上!

(例によって、ちょっと嵌まりましたorz )

 

DockerコンテナのUbuntuで試してみた (失敗)

openSUSE Leap 15.3のDockerでも、docker pull ubuntuしてみたら、あっさりUbuntuが動きました!

ということは、UniFi Network Applicationも行ける?

早速、下記サイトからパッケージをダウンロードして、apt install ./unifi_sysvinit_all.deb してみたものの、インストールがうまくいきません。

インストーラにsystemdを想定した処理が含まれているのですが、dockerコンテナの中ではスタートアップ周りがサポートされていないので、ずっこけてしまいます。

_(:3」∠)_

スタートアップスクリプトらしいものを手で叩いてみるのですが、エラーが出てしまい、動かすのは大変そうです。

というわけで、あっさり やめた!

 

Dockerイメージがあった

誰かDockerでUniFi controllerを動かしていないかなと検索してみたら、なんと linuxserver/unifi-controller という名のDockerイメージが配布されているじゃぁありませんか!

hub.docker.com

半信半疑ながらも、openSUSEの上でpullして実行してみました。

  # docker pull linuxserver/unifi-controller
  # docker run -it -h unifi linuxserver/unifi-controller bash

ps axで見ると、しばらくしてmongodやjavaが動き始めて、なんとなくうまくいっている予感がしてきました。

では、同じホストからアクセス。Dockerコンテナに割り振られたIPアドレスを調べてから、

  $ firefox https://172.17.0.2:8443

成功!

なお、最初にポート8080を使ってhttpでアクセスしてしまい、これでも初期設定画面は表示されたのですが、最終段階でクラウドの認証が通らない状態になって、しばらく悩みました。同じ現象に遭った人がちらほら。

httpsの8443番からアクセスしましょう。サーバ証明書の検証に失敗しますが、ここは強行するしかありません。

 

クラウド側からのアクセスを確認

ローカルでコントローラが立ち上がって、クラウドの認証も通ったら、クラウド側からアクセスできるかどうか確認します。https://unifi.ui.com/ からログインしてみると、例によってそこには見当たらないので、View Legacy Platform に進みます。

いました! (一番上の子)

UniFiコントローラ (クラウド)

 

LAUNCHからクラウド経由でもコントローラ画面を出してみましたが、少しWebRTCに引っかかりを感じるものの、なんとか動いているようです。

ネットワークの本設定はこれからなので、未確認で進行形です。
(基地局をつなぐには、dockerのネットワーク設定を変更して、コンテナを外に出してあげる必要があります)

 

ちなみに、このdockerイメージでは、コントローラのログが /var/log/unifi ではなく、/usr/lib/unifi/logs の下にありました。(ぁ、やっぱりSTUNが時々コケている……)

 

おわり

 

 

jp.store.ui.com