0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kaz32

Qua Station(RTD1295)をClaude CodeでUbuntu 26.04＋mainline Linux 6.18導入記録（5・番外編）Bluetooth非常口編

0
Last updated at Posted at 2026-09-22

先に結論を書きます。(1)〜(4)の作業と並行して、実はBluetooth経由の緊急ログインコンソールも仕込んでいました。ただし、一番使いたかった場面では原理的に使えないという設計ミスが後から判明し、結果的に自己満足の作業に終わりました。 番外編として、その顛末を書きます。技術的な工程自体は普通に面白い(&実用にもなる)ので、笑い話として読みつつ参考にしてもらえればと思います。

なぜBluetoothなのか

QuaStationは自宅内でADS-B(航空機追跡)関連の常時稼働機として使っています。もしネットワーク設定を壊して疎通不能になった場合、物理的にアクセスする手段が(1)で触れたシリアルコンソール以外に無いのは心もとない、と考えました。そこで、IPネットワークに一切依存しない経路として、Bluetooth SPP(Serial Port Profile)——Bluetooth越しに仮想シリアルポートを提供する仕組み——を使ったログインコンソールを整備することにしました。「ネットワークが死んでも入れる」が売りのはずでした。

5つの障害を順番に踏み抜く

やってみると、単純な「UARTをBluetooth化するだけ」では済まず、5つの障害を順番に踏み抜くことになりました。ここは実際に技術的な収穫があった部分です。

# 症状 原因 対処
1 Bluetooth自体が沈黙 UART1用の4ピンがGPIOモードのまま（レジスタ0x98007310のbit14/16/18/20が0x0＝GPIO） 0x00001400→0x00155400に書き換え。この値は再起動で揮発するため、専用のsystemdサービスとして起動のたびに再設定するよう恒久化
2 作ったSPPサービスがリモートから見えない sdptool add SPで追加したSDPレコードは「Public Browse Group」に登録されない（bluezの既知の癖）。リモート側はbluez標準の5個しか見えず、追加した分だけ見えなかった D-Busのorg.bluez.ProfileManager1.RegisterProfile経由の正規の登録方法に切り替え
3 WindowsがCOMポートを作らない BluetoothのClass of Deviceが0x000000(Miscellaneous)のままだった /etc/bluetooth/main.confでClass = 0x000104(Computer/Desktop)に設定。Windows側レジストリにCOMポート用のサブキーが出現したことで確認
4 agetty: cannot get controlling tty rfcomm watchで起動した子プロセスはセッションリーダーになれないため、制御端末を掴めない 一時対応としてsetsid --waitを挟む（最終的にはD-Bus方式へ移行しrfcomm自体を廃止したため不要に）
5 Windows接続直後に切断(DISC)される rfcomm起動オプションの-A -E（認証・暗号化の強制）をWindows側が満たせなかった。btmonでリンクは既に暗号化済みと確認済みだったため、この強制は不要だった -A -Eを外す

さらに、/bin/loginをそのままPTY越しに使うとInput/output errorで即死する問題もあり、agetty -L - 115200 vt100に切り替えて解決しています。-はポート指定を「標準入力をそのままttyとして使う」という意味に、-Lはローカル回線として扱いキャリア検出(CD)を無視する、という別々のオプションです。

おまけの珍事: 「開通した」と自分で誤報した

5つの壁を越えた後、翌日に振り返ったところ、実は前日「Bluetooth経由でログインできるようになった」と報告した内容自体が誤りだったことが分かりました。実際にログインが通ったわけではなく、login:というプロンプト文字列が表示されただけの状態を、開通したと早合点していたのです。原因は、ログイン先アカウントのパスワードがロックされたままで、誰も認証を通過できていなかったこと。

昨日の「SPP疎通成功」は誤報だった。出ていたのはlogin:の文字列だけ。パスワードがLockedだったから、あの時点で入れたはずがない。私はプロンプトが出たのを見て「開通」と書いた。最後まで通してなかった。

「経路ができた」ことと「実際にシェルが取れる」ことは別物、という教訓です。パスワードのロックを解除し、Windows側から

New-Object System.IO.Ports.SerialPort "COM5",115200,...

でCOM5に接続してシェルが取れることを確認し、ここでようやく本当の意味での開通となりました。さらに発展させて、別のPC(Windows 11機・N150ミニPC)経由でワンクリック接続できるショートカットも用意し、「開発用PC→(SSH/Tailscale)→Windows 11機(N150ミニPC)→(Bluetooth SPP)→QuaStation」という3段構成の緊急時リモート実行経路まで作り込みました。

まあ、使う日が来ないのが一番いいんだけど

本題: 一番使いたい場面で、原理的に使えなかった

ここが今回の一番の顛末です。(4)で扱ったext4破損の対応中とは別に、同じ時期にUSB機器の抜き差しがきっかけで実機がブートループに陥り、Wi-Fi・Tailscaleを含む全経路が無応答になったことがありました。「ネットワークが死んだ時のための非常口」の、まさに出番のはずです。

確認すると、Bluetooth経路も無応答でした。

原因は設計そのものにあります。今回作ったBluetooth非常口は、専用のハードウェア(UART)を直接掴んでいるとはいえ、実体はOS起動後にuserspace上で動く1本のPythonブリッジです。つまりOS自体がブートループに陥って一度もuserspaceまで上がらない状況では、BTブリッジも一緒に死ぬ構造でした。「ネットワークが死んでもアクセスできる」を目指して作ったはずが、想定していた最悪のケース（OSごと起動できない）には原理的に無力だったわけです。

正直に言うと、「非常口を作った」という達成感だけが先行し、本当に守りたかった場面をカバーできていなかったという、笑うしかない結末でした。無駄だったとまでは思っていません。Bluetoothスタックの癖・Windows側の仮想COMポートの挙動・PTYの扱いといった知識は今も財産ですし、userspaceが生きている範囲の障害（(4)のext4破損のような）では引き続き有効です。ただ「本当の意味での非常口」にするには、OSに依存しないハードウェア側の仕組み（ウォッチドッグによる自動リセットなど）と組み合わせる必要がある、というのが正直な現在地です。

おわりに

「シリアルコンソール以外の緊急アクセス経路が欲しい」という単純な動機から始め、技術的には5つの壁を越えて実際にBluetooth経由のログインコンソールを完成させました。ただし本当に必要になった場面（OSごと起動しない障害）では原理的に無力だと後から判明し、結果的には笑い話に終わっています。

元も子もないことを言うと、OSごと起動しなくなるレベルの障害では、結局(1)のシリアルコンソールに頼らざるを得ないというのが今回の結論です。userspace上で動く非常口には、userspaceが死んだ瞬間に道連れになるという原理的な限界があり、これを超えるにはハードウェアに近いレイヤーの経路（シリアル、あるいはウォッチドッグ）以外に手が無いのだと思います。「シリアルを使わずに済ませたい」から始まったシリーズが、最後には「結局シリアルが一番強い」という当たり前の結論に着地する、という締めくくりでした。技術的な工程そのものは他の組み込みLinux機でも応用が利くはずなので、同じ発想で非常口を作る人の参考になれば幸いです。このシリーズはここまでです。読んでいただきありがとうございました。

ビルド成果物の公開

同じ機種で試したい方向けに、ここまでの全修正（SSD移行・SATA/PCIe/Wi-Fi/LED・USB2.0/PCIe診断ログ対応）を含む最終版のカーネルソース・Image・DTBをGitHubで公開しました。ソースは(2)で触れた通りGPL-2.0の派生物としてsymops/monarch-6.18をフォークする形で公開し、コンパイル済みのバイナリもReleaseとして添付しています。rootfs側については公開していませんが、公開の基準を満たせる状態になればこちらも公開しようと考えています。それまでは(1)(3)に書いた手順（公式Ubuntu Baseからの構築）で各自作成していただければと思います。

公開ファイルのハッシュ値（実機の稼働中BOOTパーティションから直接取得した、現在動いているビルドそのものです）:

30f74fe861f129ce4b8cf7e25dc6fd33ea5d22cd0738a436256f20c38583c19b  uImage (17,166,848 bytes)
e0a71d92fd98f5fcaa2b331e8e94b4b24d23dfe038b4150c27df56e8ce88984f  QuaStation.dtb (33,639 bytes)

Releaseに添付したファイルのハッシュと一致することを確認しています。

参考文献（シリーズ共通）

今回の移植は先人の資産の上に成り立っています。ベースにしたもの・参照したものを、実機（Qua Station）に近い国内発の情報源、同じSoCの海外コミュニティ情報源、および各種公式ドキュメントに分けて挙げます。

国内（Qua Station実機ベース）

海外（同じRTD1295系SoCのコミュニティ資産）

Wi-Fiファームウェアのライセンス

Bluetooth / D-Bus

ファイルシステム復旧（e2fsprogs）

シリーズ目次

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?