【はじめての方へ】SoftBank Air ターミナル6 OpenWrt テスト版・インストール相談・A/B起動ガイド

[Karin-Laboratory]

SoftBank Air ターミナル6でOpenWrtを動かしてみたい皆さん、こんにちは！ 開発者のカリンです。😊

「自分も試してみたいけれど、何から始めればいいかわからない」

「LinuxやOpenWrtに詳しくないけれど、使ってみたい」

そんな方にも参加していただけるよう、テスト版の入手方法、インストールに関する案内、質問や動作報告を、このスレッドにまとめることにしました！

1. どこまで動いているの？

私の実験機では、Linux 6.18.44とOpenWrtの起動に成功しています。

確認できた機能は、有線LAN、SSH、2.4GHz／5GHz Wi-Fi、LTE IPv4通信などです。

ただし、まだ開発途中です。すべての機能が完成しているわけではなく、電源投入からの安定動作や、失敗した場合の復旧方法などにも未解決の問題があります。

2. テスト版の入手

実験用ビルドの配布には、ギガファイル便を利用します。

配布URL：https://7.gigafile.nu/0202-c2b4f96ee6bd050edd35b8dd009dfa29c

バージョン・対象機種・同梱資料については、配布時の案内をご確認ください。

GitHubでは、ソースコード、DTS、パッチなども公開しています。

https://github.com/Karin-Laboratory/openwrt-terminal-6

なお、GitHubの公開ソースだけで、実験機と同じファームウェアを完全に再現できる状態にはまだ至っていません。

また、テスト用の過去のビルドにはrootパスワードが未設定のものがあります。そのままインターネットや普段使いのLANに接続しないようご注意ください。

3. インストールとA/B起動の仕組み

Airターミナル6には、A/Bという2系統の起動領域があります。

これは、ひとつの機器に2組の起動用ソフトウェアを持たせる仕組みです。

通常はソフトウェア更新の際に使われますが、OpenWrtの実験にも利用できます。

私の実験では、片方に純正OSを残し、もう片方でOpenWrtを動かしています。

3-1. A/Bとは何か

イメージとしては、次のような構成です。

項目	Slot A	Slot B
起動イメージ	boot_a	boot_b
ルートファイルシステム	rootfs_a	rootfs_b
私の実験機での用途	OpenWrt	純正OS
通常起動	起動先として選択可能	起動先として選択可能

※この表は私の実験機での構成です。出荷時に必ずB側が選択されているという意味ではありません。

A/Bのどちらから起動するかは、ブートローダと起動管理情報によって決まります。

この管理情報には、優先順位、起動試行に関する値、正常起動の記録などが含まれています。

つまり、A/Bは二つのOSを同時に動かす仕組みではなく、どちらか一方を選択して起動する仕組みです。

3-2. 実際のパーティション構成

私の実験機で確認した主なパーティションは以下の通りです。

パーティション	名前	役割
p1	misc	A/Bの起動管理情報
p23	lk_a	A側ブートローダ
p25	boot_a	A側カーネル等、32MiB
p26	rootfs_a	A側rootfs、128MiB
p36	lk_b	B側ブートローダ
p38	boot_b	B側カーネル等、32MiB
p39	rootfs_b	B側rootfs、128MiB

OpenWrtの実験では、主にboot_aとrootfs_aを使用しました。

純正OS側のboot_bとrootfs_bは残しています。

ただし、A/Bの二つの領域があっても、Preloaderなど共通の起動処理や、別領域に保存される設定もあります。

A/Bがあるからといって、機器全体が二重化されているわけではありません。

3-3. /sbin/quec_bootctrl とは？

純正OSには、A/Bの起動先を管理するためのメーカー独自ツールがあります。

私の実験機で使用したことを確認できているのが、次のプログラムです。

/sbin/quec_bootctrl

これは、起動管理情報を変更して、次回の起動先を選択するためのツールです。

過去の実験では、このツールを使ってA側を優先する状態に変更し、再起動によってOpenWrtの起動に成功しています。

ここで大切なのは、このツールがOpenWrtをインストールするわけではないということです。

役割を分けると、次のようになります。

• boot_a、rootfs_a：起動するソフトウェアの実体を保存する領域
• misc：A/Bの起動管理情報を保存する領域
• quec_bootctrl：起動管理情報を変更する純正ツール
• Preloader／LK：管理情報や署名等を確認し、起動処理を進めるブートローダ

なお、quec_partctrlなど似た名称のツールと混同しないよう、実機で正確なファイル名とオプションを確認する必要があります。

具体的な切替パラメータは、機器の状態によって安全性が変わるため、ここでは一律に指定しません。

3-4. 自分のAir6の状態を調べるには？

すでにroot権限でシェルに入れる場合、まずは現在の起動状態を確認します。

例えば、以下は情報を表示するだけのコマンドです。

• cat /proc/cmdline：カーネル起動時の設定を確認
• cat /proc/partitions：認識されているストレージ領域を確認
• ls -l /sbin/quec_*：利用可能な関連ツールを確認

起動設定にbootslot=aまたはbootslot=bが含まれる環境では、それも判断材料になります。

ただし、OSによって表示内容が異なることがあります。実際の起動先は、起動ログやパーティション情報も合わせて確認します。

また、純正OSと実験用Linuxでは、同じeMMCでも/dev/mmcblk0と/dev/mmcblk1のようにデバイス番号が変わった実例があります。

そのため、他人のコマンドに書かれたデバイス名を、そのまま使用することはできません。

root権限がない状態からの調査については、個別にご相談ください。

3-5. OpenWrtから純正OSへ戻せるの？

実際に戻れた事例はあります。

私のTest34では、OpenWrt側のカーネルが起動中にパニックを起こした後、再起動時に純正B側が選択されました。

その結果、純正Linux 5.4.238が起動し、LANとSSHが復旧しました。

一方、Test35ではA側に留まった事例もあります。

つまり、異常終了すれば必ず自動的に純正へ戻る、という動作は確認できていません。

また、A/Bの起動管理情報は単純なカウントダウンだけで動いているわけではない可能性があります。実験では、起動前後にカウンタ値が増加した事例も確認しています。

このため、現在の起動状態が不明なまま切替コマンドを試すことは推奨しません。

純正カーネルが正常に起動できる状況では、UART経由で救出シェルを起動し、設定を復元できた別の実績もあります。

ただし、A/B両方の起動イメージが破損した場合の確実な復旧方法は、まだ確立できていません。

3-6. 初めて試す方へ

次のような順序で進めることをおすすめします。

1. まず自分のAir6の型番と現在の状態を確認する。
2. root権限の取得や管理用接続について、必要なら個別に相談する。
3. 現在の起動スロット、パーティション構成、ブートローダの状態を調べる。
4. データのバックアップと、失敗した場合の復旧方法を確認する。
5. それからテスト版の導入が可能か判断する。

最初からすべてを理解している必要はありません。

ただし、書き込みや起動スロットの変更については、復旧手段が確認できるまでは実行しないようお願いします。

私自身も試行錯誤しながらここまで来ましたので、分からないことがあれば遠慮なく聞いてください！

4. root取得について

root権限の取得方法や、起動に必要な署名に関する情報については、現行製品のセキュリティへの影響を考慮し、一般公開を控えています。

個別のご相談はお受けしています。

Xでフォローいただければ、フォローバック後にDMで事情を伺い、対応を検討いたします。

https://x.com/verandavineyard

公開範囲に関する方針はこちらです。

#48

5. 質問、大歓迎です！

「UARTって何？」「SSHってどうやるの？」「そもそも何を準備すればいいの？」

どんな質問でも、まったく構いません！

ご質問の際は、Air6の型番、現在の状態、試してみたいことなどを教えていただけると、案内しやすくなります。

作業に失敗した場合も、慌てて再書き込みせず、表示やログを残してご相談ください。

パスワード、秘密鍵、SIM情報などは投稿しないようお願いします。

6. 一緒に育てていきましょう！

このプロジェクトの最終目標は、OpenWrt公式へのマージです。

でも、その前に、興味を持った人が気軽に参加できるようにしたいと思っています。

動作報告、不具合、改善案、質問、どれも大歓迎です。

「自分もやってみたい！」という方、どうぞお気軽にコメントしてください！ 😊

Karin

[Karin-Laboratory]

【補足案内】テスト版のWi-Fi接続情報について

テスト版をお試しの皆さんへ、Wi-Fi接続について補足します。
配布した実験用ビルドは、WiFiAPにパスワードがあります。
ご案内が不足して申し訳ございません。
PSK：
ad712bf5d36502f293632da41dd197f6
対象：https://7.gigafile.nu/0202-c2b4f96ee6bd050edd35b8dd009dfa29c

[rk2kk]

実験ファームのメモです。
Wi-Fi 接続後の通信確認は 192.168.24.1 (ping) で行えます。 SSH 管理は有線 LAN2 の 192.168.3.1 のみです (Wi-Fi 側では SSH は動作しません)。 有線側は DHCP がないため、接続端末に 192.168.3.x/24 の静的 IP を設定してください。

[Karin-Laboratory]

rk2kkさん、接続情報の補足ありがとうございます！😊とても助かります！
こうして実験ファームの情報を共有していただけるのは本当にありがたいです。今後ともよろしくお願いします！

[rk2kk]

6ghzでの通信も確認できました

[uni-uni-77]

prplmeshの導入とknosのスクリプトを使用しないEasymesh Controller/Agentは可能でしょうか？

[Karin-Laboratory]

uni-uni-77さん、コメントありがとうございます！😊

prplMeshによるEasyMesh Controller/Agentの実現は、私も以前から関心を持っているテーマです。

ただ、現時点では具体的な調査や実装にはまったく着手できていません。

現在はAir Terminal 6へのOpenWrt移植と、基本機能の安定動作を優先しています。

過去にWi-Fi APの動作は確認できていますが、EasyMeshに必要なドライバ機能やprplMeshとの互換性、KNOSのスクリプトに依存しない実装の可否など、すべて未調査・未検証です。技術的には実現の可能性があると考えていますが、現段階では何とも言えません。

もしご関心があれば、prplMeshのOpenWrtへの導入方法や、MediaTek無線ドライバとの互換性について、調査からご協力いただけませんか？

調査結果をDiscussionで共有していただくだけでも大変助かりますし、実装にも挑戦していただけるなら、IssueやPull Requestを通じて一緒に開発を進められたら嬉しいです。

GitHubの大きな魅力のひとつは、こうして関心を持つ人たちがそれぞれの得意分野で参加し、開発を加速できることだと思っています。

ちなみに、ControllerとAgentの両方を想定されていますか？ 想定されている用途もぜひ教えていただけると嬉しいです！