hgot07 Hotspot Blog

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

Wi-Fi HaLow で Passpoint / OpenRoaming を使う (HaLowLink 2編)

前回の宿題になっていた、Wi-Fi HaLow で Passpoint を使おうという話です。

基本は WPA3 Enterprise なので、まずは前回の記事に従って、設定を済ませておきます。

hgot07.hatenablog.com

今回、Morse Micro HaLowLink 2 (firmware 2.11.13) を使いました。

 

基地局(AP)側のPasspoint有効化

HaLowLink 2 に ssh でログインして、hostapd_s1g を strings コマンドで覗いてみると、hs20 関係のラベルが見えます。つまり、hostapd は Passpoint に対応しているということでしょう。

幸いなことに、UCI (Unified Configuration Interface) も Passpoint に対応したものが入っていて、/etc/config/wireless の config wifi-iface セクションに Passpoint 関係の設定を追加してやるだけで、 /lib/netifd/hostapd.sh がうまいこと設定を hostapd_s1g に引き渡してくれます。

例えば次のような行を追加すると、OpenRoaming の RCOI を吹くようになります。各パラメータの値は自分のサイトに合わせる必要があります。

        option hs20 '1'
        option hs20_oper_friendly_name 'eng:HaLow-Passpoint'
        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_osen '0'
        option iw_venue_group '2'
        option iw_venue_type '8'
        option iw_hessid '<HaLow用インタフェース (wlan0など) のMACアドレス>'
        list iw_roaming_consortium '5a03ba0000'
        list iw_venue_name 'eng:PasspointLab'
        list iw_venue_url '1:https://example.com/'
        option iw_network_auth_type '00'
        option iw_ipaddr_type_availability '0c'
        list iw_domain_name 'example.com'

おや? hs20_operating_class は?

とりあえず無くても動くようです (ぇ

IEEE 802.11 の仕様を見ても、Sub-1G で Operator Class をどのように扱うべきか、よく分かりませんでした。Morse Micro の実装では、S1G は 5GHz 帯にマッピングした値を使っているとのことでした。

 

クライアント(STA)側のPasspoint有効化

執筆時点 (2026/9/23) のファームウェアのリリースは OpenWrt 23.05.6 Morse-2.11.13 でした。

残念ながら、クライアント側の設定を wpa_supplicant_s1g に渡す仕組みが、まだ UCI に組み込まれていません。本家の OpenWrt 25.12 でさえ非対応です。

とりあえず wpa_supplicant_s1g は Passpoint に対応していそうなので、パッチを作ってみました。

github.com

OpenWrt なら /lib/netifd/hostapd.sh を書き換えるだけで済むのですが、Morse Micro 専用のスクリプト /lib/netifd/morse/morse/morse_overrides.sh の方もいじらないといけません。次のようにして、二つのスクリプトにパッチを適用します。(OpenWrt 版ではなくLinux などの patch コマンドを使う方がよいみたいです)

$ patch -p0 hostapd.sh < hostapd.sh.patch
$ patch -p0 morse_overrides.sh < morse_overrides.sh.patch

 

/etc/config/wireless の config wifi-iface セクションに、Passpoint 関係の行を追加します。OpenRoaming ならば、以下のとおりです。

       option iw_enabled '1'
       option iw_rcois '5a03ba0000'
       option ieee80211w '2'

Wi-Fi HaLow では WPA2 ではなく WPA3 (PMF必須) を使うことが強く推奨されているので、11w (PMF) を Required (=2) に設定しておくのがよいでしょう。

あとは、wifi コマンドで設定を反映するだけです。wpa_supplicant_s1g に渡される設定ファイルが /tmp/run/wpa_supplicant-wlan0.conf に書き出されているはずです。

 

おわりに

いくら Passpoint / OpenRoaming に対応した Wi-Fi HaLow 基地局を立てても、クライアントデバイスが非対応では意味がありません。計算資源が著しく限られたものは仕方ないとしても、様々な IoT デバイスが Passpoint に対応してくれることを願っています。

願うというか、Wi-Fi HaLow では Passpoint 対応を必須にするぐらいのことは、やってもらいたいところです。Morse Micro さんにも頑張ってほしい。

 

おまけは、Sydney にある Morse Micro 本社が入っているビルの写真です。ちょっとだけお邪魔してきました (・∀・)ノ (聖地巡礼?)

Morse Micro本社

Morse Micro本社

Morse Micro の名札

Morse Micro の名札

 

おしまい

eduroam JP 20周年、そしてこれから

eduroam JP 20周年記念画

eduroam JP 20周年記念画

ask_a_12さん @ twitter に頂戴した記念画です。許可をもらって掲載しています。

さて、2026年8月31日に、eduroam JP は20周年を迎えました 🎉🎉🎉

20年も経つと初期のことがあまり思い出せなくなってくるので、とりあえず思い出せる分だけでも記録として残しておきます。

最近、大学もなさそうな市街地で突然 eduroam がつながって、ビックリしていませんか? それ、我々のしわざです。後ろの方で解説していきます。

 

eduroam JP発足前夜

2006年度 (平成18年度)に、国立情報学研究所 (NII) が中心となり、8大学 (北海道、東北、東京、名古屋、京都、大阪、九州、東工大)と高エネ研が集まって、全国大学共同電子認証基盤構築事業 (UPKI: University Public Key Infrastructure) が始まりました。

今でこそ電子認証や認証連携は当たり前の社会になっていますが、20年前は大学でもまだ電子認証基盤が一般的ではなく、他大学や各種サービスと連携するための標準的な仕組みがありませんでした。

まずは調査が必要ということで、参加機関から代表が集まって、それなりの大人数で調査旅行が行われました。UPKI事業の中で、各機関がどの部分を担当するかといったことも、まだ流動的な段階でした。2006年7月にアジア太平洋地域のネットワークなどに関する会議 APAN meeting がシンガポールで開催されることになり、まずはここから調査開始です。

続いて、電子認証基盤で進んでいるオーストラリアの事例を調査するために、AARNet や The University of Queensland (UQ) を訪問することになったのですが、日程が近いため、シンガポールからオーストラリアにハシゴすることになりました。しかも、シドニーに滞在しながら、7/24にブリスベン日帰り、7/25にキャンベラ日帰り、7/26にAARNetのシドニーオフィス訪問という、強行軍でした。

 

日本のeduroam参加

UPKI事業において、認証連携の分かりやすい事例として、各大学のキャンパス無線LANを相互利用する仕組みを作ってはどうかという話が、当初からありました。具体的な方式の目途もないまま、何も知らない調査団が現地で見たものは……

「eduroamというシステムがあって……」

え、なにそれ?良さそうじゃないか。もうあるなら試してみよう!

恐ろしく早い決断で、とりあえずeduroamの名前は押さえておくべきということで、会議場からNIIにメールを送り、「eduroam.jp のドメインを取ってほしい」と。whois で見るとドメインの登録日が 2006/07/26 になっていて、歴史を物語っています。

とりあえず、RADIUSによる認証連携の簡易レクチャーを受けてから帰国し、RADIUSのお勉強です。当時、APAN地域では、オーストラリアの他に台湾と香港Poly-Uがeduroamに参加しており、APAN用のRADIUS proxyの一つはAARNet、もう一つはHK Poly-Uで運用されていました。東北大学でFreeRADIUSのサーバを立ち上げて、APANのRADIUS proxyに対してradtestで最初にAccess-Acceptになったのは8月24日でした。

その後、NIIから正式に「eduroamに参加しました」というアナウンスが出て、2006年8月31日が公式のeduroam JP発足日となりました。

2006年12月にNII、北大、京大、高エネ研が東北大に接続して、国内運用が始まりました。

  • 東北大学と日本のeduroamについて [PDF]

なお、世界のeduroamは、2002年にTERENA (現在のGÉANT)のタスクフォースから始まったものです。オーストラリアが接続されたのが2004年12月で、日本の参加は世界的にも早い方でした。台湾が早期に無線網路漫遊として国内でローミングを実現していたようですが、eduroamとの関係が当時はよく分かっておらず、接続の検証もできませんでした。香港が先に接続していたことから、出遅れたようで少し残念な気持ちでした。それでもEU外のUSやカナダ、中国の参加までさらに数年かかっているので、この早さは十分に自慢できるでしょう。

国内では……、初期の参加機関数がなかなか伸びなくて、苦労しました。キャンパス無線LANを訪問者に使わせることについて、「なにかあったらどうするんだ!」という日本の事なかれ主義が邪魔をしているのかもしれません。有益なものの導入を邪魔して不利益が生じた責任は、誰がとるんですかねぇ。

2026年8月時点の参加機関数は487で、国内の高等教育機関が1,170ぐらいあることから見ると、まだまだ遠いなと思います。(2006年当時は1,220ぐらいあった気が)

 

市街地eduroamの歴史 (2009-2020)

国内外のeduroamでは、市街地でも使えるようにしたいという要望が初期の頃からあり、一部の国では地元の大学の協力などにより基地局が設置されていました。大学の最寄りのパブでeduroamが使えるとか、空港で使えるとか、羨ましく思っていたものです。

国内でも似たようなことができないだろうかと、色々と画策していたのですが、公衆無線LANの事業者と話し合ってもやはり費用面で折り合いが付かない状態でした。局舎にラックを借りろとか、無茶苦茶な費用を提示されたりしました。

さらに困ったことに、せっかく会議場がeduroam導入に前向きになっても、大手の通信事業者が関わった時点で、いつの間にか話が消えていることが何度かありました。要するに、当時の事業者がWPA2 Enterpriseをまともに扱えなかったということでしょうに。

一応、国内でも市街地eduroamの先進事例があり、昔の記事に書いてあります。

hgot07.hatenablog.com

livedoor Wireless (後にNHNテコラス) のご厚意により、提供されていたものです。しかし、関東圏から外に出ることはなく、他の施設に波及することもなく、2020年にサービス終了となりました。

 

市街地eduroamの現在 (2020-)

eduroamはWPA2 Enterpriseによる安全な無線LAN利用を実現していますが、利用者が教育研究機関の構成員 (学生も含む)に限られるという制約があります。市民向けのフリーWi-Fiでも、eduroamと同様の安全性と利便性を有する仕組みを導入したいということで、Cityroam というローミング基盤が2018年に開始されました (というか、我々が作りました)。

cityroam.jp

さらに、Wireless Broadband Alliance の OpenRoaming が2020年に開始され、Cityroamがメンバーとなって、国内でOpenRoamingの展開が始まりました。

openroaming.jp

wballiance.com

実は、CityroamもOpenRoamingも、認証連携の基本的なアーキテクチャは eduroam と同じです。

datatracker.ietf.org

ということは、市街地にOpenRoamingの基地局が並ぶようになったら、eduroam とのローミングも容易なのでは?🤔

その通りです!!

ただし、OpenRoaming では Passpoint の技術が使われていて、SSID = eduroam を使う標準的な eduroam とは異なる接続方法になっています。これでは eduroam 利用者がキャンパス無線LANと同様に利用することができないので、利便性が著しく悪くなります。

端末に特別な設定の追加をせずに、そのまま市街地で eduroam を利用できるようにするため、Cityroamでは SSID = eduroam を併設することにしています (*1)。これにより、東京や大阪などの大都市を含む国内20以上の自治体のフリーWi-Fiで、市街地eduroamが実現されています。

一つ注意点があります。Cityroam などが提供する市街地eduroamのサービスは、あくまでフリーWi-Fiが本体で、SSIDの併設によって接続方法の便宜を図っているというものです。eduroam のアカウントを用いて、認証連携によって、(安全な) フリーWi-Fiに接続できるようにするという仕組みになっています。技術的には、わざわざ eduroam の回線を引っ張ってきたわけではありません (一部の基地局を除く)。自治体の立場では、eduroam 回線を引っ張ってきたように 見せたい かもしれませんが、それも間違いではないでしょう。もろもろひっくるめて、安全な次世代のフリーWi-Fiを整備したわけですから👍

 

*1: 自治体などのオーナーや、通信事業者、コンサルタントに注意していただきたいことがあります。Cityroam 以外のプラットフォームで OpenRoaming を整備した場合、同じRADIUSプロキシに eduroam の SSID を追加しただけでは、認証が通らないことがあります。eduroamの併設には、プロキシに特別な設定が必要です。さらに言うと、eduroam JP への参加なしにこのような実装をすることは、eduroam の規約違反となります。

 

2026年時点で、OpenRoaming も市街地eduroamも、他国が羨むような先進事例となっています。有効活用しましょう。

 

eduroamのこれから

市街地eduroamの枠組みができて、なんとコミケ会場の東京ビッグサイトでも常時使えるようになって、SNSでは驚いている人がちらほら見えます。インフラとしては、水道や電気と同様に、驚いてもらえるうちが華という悲しい側面もあります。しかし、とりあえずしばらくは驚いてもらえると思います。

さて、今後のeduroamは、どのようになるでしょうか?いくつかのプロジェクトが走っていますが、驚きそうなものはお楽しみということで☺️

地味なものも含めて、課題になっているものを少し紹介します。

  • まだeduroamに参加していない半数以上の大学をどのようにサポートしていくか?導入における困難があるなら、技術面や運用方法、導入方法での対策を考える。
  • eduroamは、国別統計が取得しやすい、教育研究に貢献しているというポーズがとれるといった利点があるのに、OpenRoamingだけ導入しようとする自治体が若干ある。理由の分析と対策を考える。
  • 一般に市民はキャンパス無線LANに接続できないので、未参加機関からの研究者や、市民講座などで、ゲストアカウント発行などの手間がある。大学にも OpenRoaming があれば、解決策になる。大学に eduroam と OpenRoaming をセットで展開していく方策を考える (NIIで計画中)。
  • 小中高にもeduroamやOpenRoamingを導入できるようにして、ネット時代の学習・教育環境を推進する。避難所に指定されている学校では、被災時の安全なネットワーク利用環境にもなる。

 

おわりに

2026年度内を目標に、アッと驚くようなことを二つほど準備中です。まだ流動的ですが、実現できるといいなぁ。

市街地eduroamで仕事が捗ったなど、有効活用ができたら、自治体などのスポンサーに伝わるように褒めてあげましょう。次の展開につながるかもしれません。

 

おしまい

Chromebook を OpenRoaming に接続する (TOKYO Free Wi-Fi など)

結論から書くと、Passpoint の仕組みでは、できません!

 

以前は Cisco OpenRoaming アプリでなんとか使うことができたのですが、2026年8月時点で再度試してみたところ、使えなくなっていました。うーん、この Google ……

hgot07.hatenablog.com

Passpoint の設定ができるアプリでもあればよいのですが、残念ながら無さそうです。Android 版の geteduroam でできそうだと思ったのですが、設定がうまく入らないようです。

 

仕方がないので、SSID を決め打ちにして、WPA2 Enterprise の設定で接続することにします。

 

Passpointが使えないと何が困るのか

OpenRoaming で使われる Passpoint は、最近の多くの端末でサポートされるようになりましたが、安定しない機器もあるようです。

Passpoint とは何なのか、極限まで端折って書くと、SSID が違っても自動接続できる仕組みです。OpenRoaming に対応した自治体Wi-Fiでは、自治体ごとにSSIDが違いますが、どこかで作成した Passpoint プロファイルを端末に仕込んでおけばどこでも接続できます。

Passpoint が使えない場合に何か困るかというと、要するに、SSID ごとに接続設定が必要になります。ID・パスワードが共通でも、これでは激しく面倒くさいですね。

 

ONCファイルを使おう!

TOKYO Free Wi-Fi などでは、OpenRoaming の設定がうまくできない端末のために、WPA2 Enterprise の設定方法が案内されています。ウェブでID・パスワードなどの設定情報を見ることができるので、頑張って手動設定していくこともできます。

ChromeOS の Wi-Fi 設定を使ってチマチマと設定を入れていく手もあるのですが、行く先々で SSID からすべての設定を入れていくのは面倒です。ここでは、ONCファイルを使って、ちょっとだけ楽をする方法を紹介します。

ONC とは、Open Network Configuration の略です。(残念ながら、このファイル形式が Passpoint に非対応なのです)

ONCファイルを一度書いてしまえば、あとは SSID の部分だけ書き換えて、Chromeブラウザの chrome://network にあるインポート機能で読み込ませるだけで、設定が量産できます :-)

 

テキストエディタを使って、wifi-config.onc みたいな名前で、ONCファイルを書きます。中身は JSON 形式です。

例えば、TOKYO Free Wi-Fi 用のファイルは、以下のようになります。

 

{
    "Type": "UnencryptedConfiguration",
    "NetworkConfigurations": [
        {
            "GUID": "5DBEC188-9339-11F1-A89F-CA787DD52ECC",
            "Name": "cityroam",
            "Remove": false,
            "Type": "WiFi",
            "WiFi": {
                "AutoConnect": true,
                "EAP": {
                    "AnonymousIdentity": "anonymous@tokyo.wi2.cityroam.jp",
                    "Identity": "xxxx@tokyo.wi2.cityroam.jp",
                    "Password": "xxxx",
                    "Outer": "EAP-TTLS",
                    "Inner": "MSCHAPv2",
                    "SaveCredentials": true,
                    "UseSystemCAs": true,
                    "SubjectAlternativeNameMatch": [
                        {
                            "Type": "DNS",
                            "Value": "eap.wi2.ne.jp"
                        }
                    ]
                },
                "HiddenSSID": false,
                "SSID": "cityroam",
                "Security": "WPA-EAP"
            }
        }
    ]
}

太字の部分を、ウェブで確認した設定情報で置き換えます。

GUIDは、適当な値を入れておけばよいです。

Name と SSID の部分は、訪問先の SSID に合わせます。

TOKYO Free Wi-Fi では、認証方式として EAP-TTLS (MSCHAPv2) が使われています。事業者によって違うことがあるので、適宜変更します。

なお、EAP-TLS の場合は、このテンプレートが使えません。

サーバ認証にプライベートCAが使われている場合も、このテンプレートでは対応できません。

 

ONCファイルのインポート

既に書いてしまいましたが……、
Chromeブラウザで chrome://network を開いて、下の方にある ONC ファイルのインポート機能でファイルを読み込ませれば、設定が一発で入ります。

 

偽基地局にご注意

上のテンプレートには、偽基地局に誘導されないための、サーバ認証の機能も書かれています。念のため、サーバ認証が正しく機能するかどうかを最初に確認しておくと安心です。

サーバ認証が正しく動作しているかどうかは、わざと誤ったドメイン名を入れてみることで確認できます。誤ったドメイン名では、認証に失敗して、接続できないはずです。設定の変更は、毎回、既存の設定を消してからインポートする方が、確実なようです。

 

おしまい

 

p.s. ONCファイルの仕様は、こちら ↓ にあります。

chromium.googlesource.com

Wi-Fi HaLow で WPA3 Enterprise を使う (HaLowLink 2編)

監視カメラやスマートメーターなどの用途で、徐々に存在感が出てきた Wi-Fi HaLow ですが、まだ情報に乏しく、導入の敷居があると感じます。

Wi-Fi HaLow は LPWA (Low Power Wide Area) の一種で、2.4 GHz帯などの無線LANと比べて低速ながらも、飛距離が出るというのがウリです。しかしながら、基本的に無指向性で長距離ということは、都市部などでみんなが無秩序に基地局を立て始めたら干渉が酷いことになるのではないかと、心配しています。

2024年のWBAの会議における、とあるトライアルの報告で、広大な敷地にポツンと一つだけ基地局を置いていたことに対して、「砂漠で実験しているのか?」といったツッコミがありました。ごもっともな疑問だと思いました。

Wi-Fi HaLow でリードしている Morse Micro では、多数の基地局を並べた評価も行っているようです。しかし、都市部でどのように干渉が問題になるか (ならないか) は、まだこれからのデータ採取・分析によるでしょう。

前置きが長くなりました。この記事では、公衆無線LANのように 公衆Wi-Fi HaLow を実現できないだろうかという観点で、WPA3 Enterprise のサポート状況を紹介します。

 

なぜ WPA3 Enterprise なのか

もし多数の基地局による干渉が問題になるなら、基地局の数を減らすために、通信事業者が設置する基地局を共用するという道もありそうです。これを実現するためには、利用者ごとの認証が必要になります。PSK (Pre-Shared Key) を複数の利用者で共有することは、セキュリティ上の問題があります。

Wi-Fi HaLow では、WPA3 Personal で MPSK (Multi-Pre-Shared Key) を使うのが一般的なようです。利用者が少なく、事業者が管理する基地局が少ないうちは、これでも十分なのでしょう。しかし、運用上の手間を考えると、WPA3 Enterprise でRADIUS認証を使えないだろうかという話になってきます。

Wi-Fi HaLow で WPA3 Enterprise は使えるのでしょうか?

頭に Wi-Fi と付いているとおり、実は無線部分の周波数が違う程度で、様々な仕組みが従来の Wi-Fi と同じです。多くのデバイスが Morse Micro 製のチップとファームウェアを使っていて、基地局はなんと hostapd ベースだったりします。実際は、少し手を入れた hostapd_s1g というプログラムが使われていたりしますが、Enterprise の部分をわざと殺すようなことをしていないなら、すんなり動きそうな気がします。

 

私は Edgecore EAP112 を使って Wi-Fi HaLow デビューしました。内蔵モジュールが Morse Micro 製とはいっても、ファームウェアの更新が遅く、あまり自由度がなかったです (今後の改善を期待)。

Morse Micro は様々なデバイスを既にリリースしていたのですが、例えば HaLowLink (初代) には技適がなく、国内利用できませんでした。しばらく待つこと、やっと技適対応の HaLowLink 2 が登場しました。

www.morsemicro.com

HaLow、コニチハー!

Morse Micro HaLowLink 2

Morse Micro HaLowLink 2

仕向地として日本が正式サポートされました。パッケージも日本仕様です。

なお、国内では Wi-Fi HaLow のデューティー比が1/10に制限されていて (2026/8時点)、スループットはあまり期待できないことに注意が必要です。

入手先ですが、Mouser から買えます。間違えずに -JP 型番を注文する必要があります。1台あたり2万円台半ばでした。USからの発送でしたが、数日で発送されるのが嬉しいです。

 

ところで、この筐体に何か見おぼえがあると思ったら、GL.iNet の昔のルータと同じメーカーのようですね。

ケース比較

ケース比較

置いた時に安定するように、スタンド (ベース) が付属しています。クイックスタートガイドに従って「ニッカリ」と押し込みましょう :-)

クイックスタートガイド

クイックスタートガイド

 

エクステンダーモードの罠

クイックスタートガイドによると、「アクセスポイントモード」と「エクステンダーモード」があります。最初、子機として使うためにエクステンダーモードに切り替えたのですが、ここでハマりました。

「エクステンダーモード」というのは、Wi-Fi HaLow を上流にするブリッジモードのことでした。Wi-Fi HaLow が接続されていない場合はLANポートにIPアドレスすら出てきません。アクセスポイントを WPA3 Personal に設定した後、クライアントとなる機器を Wi-Fi HaLow に接続するためのモードです。設定用のウェブ画面にすらアクセスできなくなります。

子機として使う場合でも、ルーターとして使うなら、エクステンダーモードに切り替える必要はありません。

今回、1台目を WPA3 Enterprise の基地局として、2台目を子機としてその上流を Wi-Fi HaLow にしたかったので、両方ともアクセスポイントモードのまま使います。

 

sshアクセスとWPA3 Personalの設定

まずは、WPA3 Personal で接続できるかどうかを確認します。

色々と調べるために、ウェブの設定画面でsshアクセスを有効にします。LAN側に端末を接続して、DHCPでアドレスを取得すれば、sshで接続できます。

$ ssh root@192.168.12.1

OpenWrtベースのファームウェア

OpenWrtベースのファームウェア

やった!ヽ(・∀・)ノ

OpenWrtベースなので、色々と遊べそう。

バージョン 2.11.13 では、そのままではWANポートからのsshアクセスができませんでした。/etc/config/firewall の設定が抜けていますね……

config rule
        option name 'Allow-ssh-wan'
        option src 'wan'
        option proto 'tcp'
        option family 'ipv4'
        option target 'ACCEPT'

WPA3 Personalの設定ですが、ウェブの管理画面から行うのがお奨めです。OpenWrtと同じ画面なので、すぐに理解できると思います。

当初、/etc/config/wireless を直接いじっていたら、EAP112 と相互接続ができなくて、しばらく時間が溶けました🫠 どうやら他にも設定が必要だったようです。

というわけで、ハイ!

iperf3の測定結果

iperf3の測定結果

同じ部屋に置いてあるのに、この程度とは🤔

所々 0.00 bits/sec になっているところが気になりますが、普通の通信はできているようです。

 

WPA3 Enterpriseの設定

一旦 WPA3 Personal の設定ができていれば、/etc/config/wireless を直接いじっても大丈夫なようです。設定は、ざっくりとこんな感じ。

基地局側:

config wifi-iface 'default_radio1'
        option mode 'ap'
        option device 'radio1'
        option network 'lan'
        option ssid 'HaLow-1X'
        option encryption 'wpa3'
        option auth_server '<authのIPアドレス>'
        option auth_secret '<authのsecret>'
        option auth_port '1812'
        option acct_server '<acctのIPアドレス>'
        option acct_secret '<acctのsecret>'
        option acct_port '1813'

子機側:

config wifi-iface 'wifinet1'
        option device 'radio1'
        option mode 'sta'
        option network 'wwan'
        option ssid 'HaLow-1X'
        option encryption 'wpa3'
        option eap_type 'ttls'
        option auth 'PAP'
        option identity '<UserID@realm>'
        option password '<password>'
        option anonymous_identity '<anonymous@realm>'
        option ca_cert '/etc/ssl/certs/ca-certificates.crt'
        option domain_suffix_match '<IdPのドメイン>'

ウェブのインタフェースには、acctの設定がないようです。なんで……

WPA3 Enterpriseのウェブ設定画面

WPA3 Enterpriseのウェブ設定画面

RADIUS認証成功

RADIUS認証成功

やた!ヽ(゚∀゚)ノ

 

[2026/9/17追記] HaLowLink 2どうしを接続する場合は、LAN側のIPアドレスレンジ (デフォルトでは 192.168.12.0/24) がぶつからないように、一方を変更しておく必要があります。当たり前ですが。

 

おわりに

まだ遠距離で WPA3 Enterprise を試していないので、少し不安を抱えたまま、今回はここまで。WPA3 Enterprise ではちょっと大きなサーバ証明書・中間証明書のやり取りが必要なので、帯域幅の小さい Wi-Fi HaLow で問題が出ないかどうか、気になるところです。

WPA3 Enterprise が使えるとなると、例によって(?)、Passpoint も使えるかどうか、私、気になります!カメラやIoT機器の方も対応してくれないと困るのですが、Morse Micro の動き次第でしょうか。

なお、GitHub に公式リポジトリがあるので、技術的な敷居はあまり高くない気がします。

github.com

 

おしまい

Edgecore EAP111のWireGuard VPN機能を試す

サクサクと行きます。

以前書いたEAP105の記事とほぼ同じことを試しているだけです。設定も同じです。

 

hgot07.hatenablog.com

Edgecore EAP111について

Edgecoreから出ているWi-Fi 6アクセスポイントです。

EAP105のWi-Fi 7みたいな目玉はなく、IP55防塵防水規格をうたっていることと、廉価なことぐらいで、機能・性能的にはあまりパッとしません。しかし、あまりコストをかけずに数をばら撒きたい用途には良さそうです。

あと、実はこれがOpenRoamingのような公衆無線LAN用途では重要で、WireGuard VPNによって有線部分の保護ができます。専用コントローラではなく、Linux箱でも受けられます。(執筆時点でまだスタンドアロン環境でしか使えませんが)

 

見た目は特に味気ないはんぺんですね。

EAP111外観

EAP111外観

EAP111外観 (裏)

EAP111外観 (裏)

技術情報がネットにあまり見つからないので、実際に買ってみるまで、ちょっと不安なところがありました。特に、どのクラスのチップセットが使われているのかが、気になります。

sshでログインしてlogを覗いてみたところ、プロセッサは MediaTek MT7981 のようです。GL.iNet Beryl AX (GL-MT3000)と同じなので、WireGuardで 300Mbps は出そうな予感。段々と高まってきました。

 

設定

EAP105と同じなのでサクッと省略。

 

WireGuardの速度

こちらもサクッと、結果だけです。

iperf3の結果

iperf3の結果

あぁ、予想より少し良い感じです (・∀・)

350Mbpsはあるでしょう。

 

課題

執筆時点でまだecCLOUDからVPNの設定ができないので、大規模実装にすぐ採用できないところがつらいです。Edgecoreさん頑張って!

あと、このモデルは TIP OpenWiFi 版もあります (購入時に選択)。外付けアンテナのモデルもあります。冴えないように見えて、実力者な予感がします。

しばらく様子を見ながら、育ててみたいと思います。

 

おしまい

 

Linuxのwpa_supplicantでOpenRoaming/Passpointに接続する

2年前に、OpenWrt箱をOpenRoamingに接続する方法を書きました。Linuxではwpa_supplicantを使って接続するのですが、そういえば、その設定を記事にしていなかったなと。メモを、未来の自分へ……

 

hgot07.hatenablog.com

アカウントの取得

OpenRoamingのアカウントは、事業者でなければ発行できません。匿名利用者の悪用を防ぐ、ローミングシステムのセキュリティのためです。

上の記事などを参考にして、お好きなプロバイダからアカウントを取得してください。現在、認証方式としてEAP-TTLSやEAP-TLSが主流ですが、この記事ではEAP-TTLSを想定します。

 

Linuxのwpa_supplicant

Linuxは、ディストリビューションによってネットワーク設定が異なるところが、イケてません。メジャーなディストリビューションでも説明をカバーするのが困難なので、ここではwpa_supplicant の設定だけを示します。

執筆時点の wpa_supplicant の最新版は 2.11 です。

LinuxをWPA2 Enterpriseのネットワークに接続する方法については、ネットにいくつか記事があります。設定の基本は、wpa_supplicant.conf に

network = {
  ...
}

のようなブロックを書くことです。

OpenRoaming / Passpointの場合は、この network ブロックの代わりに、cred ブロックを使います。network ブロックは不要なので消去して、以下のように書きます。もちろん <...> の部分は各自のものに置き換えます。

country=JP
interworking=1
hs20=1
auto_interworking=1

cred={
        roaming_consortiums="5A03BA0000"
        ca_cert="/etc/ssl/ca-bundle.pem"
        domain_suffix_match="<ドメイン名>"
        username="<ユーザ名>"
        password="<パスワード>"
        phase2="auth=MSCHAPV2"
        eap=TTLS
}

roaming_consortiums は、Roaming Consortium Organization Identifier をカンマ区切りで並べたものです。例にある 5A03BA0000 は、OpenRoamingのsettlement-free (要するにFree Wi-Fi)の Baseline の値です。

ca_cert は、サーバ認証に使うルートCA証明書を指定するものです。ここでは、システムに付属する証明書ストアを指定しています。openSUSE Leapの例なので、他のディストリビューションではパスが違っているかもしれません。

domain_suffix_match は、サーバ証明書のドメイン名 (CN/SAN)を指定するものです。プロバイダから取得した値を設定します。

WPA2 Enterprise (WPA3も同様) では、サーバ認証を省略してはいけません。サーバ認証がないと、偽基地局に誘導されてID/パスワードを奪われたりする恐れがあります。

username と password には、プロバイダから取得したユーザ名とパスワードを設定します。ユーザ名にはレルム (@以降)が付いている必要があります。PasspointではないWPA2 Enterpriseでは、username ではなく identity というパラメータ名でした。

wpa_supplicant 2.11以前のcred ブロックには、anonymous_identity のようなパラメータはありません。EAP-TTLS の outer-identity は常に anonymous@レルム の形でRADIUSサーバに渡されます。つまり、任意の outer-identity を設定できない制約があります。新しい版で改良されるようです。

wpa_supplicant.conf の詳しい書き方は、こちらで ↓

 

Passpoint対応の無線LANアダプタ

2026年時点で、Wi-Fi 5 Wave 2以降の新しい無線LANアダプタの多くが、Passpointに対応しています。ただし、Linuxで使えるチップセットは限られているので、頑張って探すしかありません。

Linuxで認識できるアダプタを使うと、wlan3 のようなデバイスが見えるはずです。以下のようにしてOpenRoaming / Passpointに接続します。

# wpa_supplicant -i wlan3 -c wpa_supplicant.conf

少し待つとこのとおり ↓

接続成功例

接続成功例

この段階で、無線LANの接続は完了していますが、まだアドレスが付いていません。DHCPでアドレスを取得する方法としてdhclient が紹介されているサイトが多いのですが、openSUSEではうまく動きませんでした。代わりにdhcpcdを使います。

# dhcpcd wlan3

接続を自動化する方法はディストリビューションごとに違うので、省略します。

 

おしまい

 

TP-Link Archer TX10UB NanoをLinuxで使う

TP-Link Archer TX10UB Nano、これです。

TP-Linkお得意の、出っ張りが少ないWi-Fi USBドングルです。中身は Realtek RTL8851bu でした。

まだまだ 11ac 世代のドングルが多く出回っているのですが、11ax は色々と効率化されているので、これからの実験には新しい方を使いたいというわけで、こちらを選んでみました。

ところで、例によって製品名が長すぎて、覚えるのが大変ですよ、TP-Linkさん orz 

 

結論 (いきなり):
ちょっとどころではない、ハマりどころがありました。

 

Linuxで使えるかな?

例によって wpa_supplicant で子機として、hostapd で基地局として動くかどうかが問題です。

私はメジャーなUbuntuよりも管理が楽と考えるopenSUSE Leapを主に使っているので、これで動くかどうかも心配です。Ubuntuでは動くけど他ではダメというドライバが、結構あるので。

さて、openSUSE Leap 15.6 のPCに挿してみたところ、ストレージデバイスと誤認識されて、動きませんでした。

GitHubにそれっぽいドライバがあったので、試してみました。残念ながら、make でも dkms でも途中でエラーが出てしまいました。ちなみに、これ ↓ です。

新しいカーネルならもしかして……と、期待を込めて openSUSE 16.0 のPCに挿してみたのですが、こちらもストレージデバイスとして認識されます。なんで……

デバイス番号が違っているのかと思って、色々と調べてみたのですが、よく分かりません。GitHub Copilotくんにエラーメッセージを食わせてみました。

lsusb shows "Bus 005 Device 002: ID 0bda:1a2b Realtek Semiconductor Corp. RTL8188GU 802.11n WLAN Adapter (Driver CDROM Mode)" but this isn't a device like that. It's a Wi-Fi 6 dongle. How can I fix it?

(答え)

The (Driver CDROM Mode) message means your USB Wi-Fi dongle is presenting itself as a CD-ROM (mass storage) device instead of a network adapter. This is a common technique manufacturers use to ship Windows drivers on the dongle itself. On Linux, you need to switch the device out of CD-ROM mode and into Wi-Fi mode, then load the correct driver.

おっと、予想外の原因が!

Leap 16.0では dkms install . がエラーなく成功して、usb_modeswitch -KW -v 0bda -p 1a2b したところ、無事にphyが生えてきました。iw phy で確認できます。

 

こんなんわかるかー・・・・・(ノ`Д´)ノ彡┻━┻

 

[2026/3/24修正] なお、Tumbleweed (20260318) ではカーネルが 6.19.8 と新しく、追加のドライバは不要で、カーネルに付いてきた rtw89_8851bu が使えました。

 

STA(子機)モードの確認

wpa_supplicant.conf を書いて、wpa_supplicant を起動してみたところ、あっさりと動きました。WPA2 Enterprise に Passpoint の設定まで入れて大丈夫だったので、OpenRoaming でも使えますねこの子。

WPA2 Enterprise + Passpointで接続成功

WPA2 Enterprise + Passpointで接続成功

APモードの確認

サクサクと hostapd.conf を書いて、基地局として動かしてみました。

例によって、Passpoint / OpenRoaming の設定まで入れてみます (笑)

こちらもあっさり動作して、めでたし、めでたし!

 

なお、2.4 GHz帯は問題なく動くのですが、5 GHz帯はW52のチャンネルしか動作しません。国内において、W53とW56ではDFSが必須なのですが、このオプションが動きません。

ちょろっと調べてみた限りにおいて、RealtekのチップでDFSは働かないようです。残念。まぁ、本格運用の基地局を作るなら、ちゃんとPCIeのモジュールを使うべきでしょう。

 

おしまい