openpilot

openpilot は、comma four の openpilot に WPA3(SAE)の Wi-Fi 対応を追加する、commaai の openpilot のフォークです。個人利用向けの非公式版で、変更したカーネルを配布しています。自動ビルドのカーネルと wpa_supplicant は、実機テストなしで公開します。comma のレビューもテストも受けていないので、問題を comma に報告しないでください。

comma の同名ブランチをもとに、nightly と nightly-chestnut、実機では未確認の release-mici-staging と release-tizi-staging、計 4 つのビルド済みブランチを毎晩作り直します。wpa3-ci ブランチには配布用の openpilot 本体ではなく、それを作るワークフロー・スクリプト・パッチを置いています。Nightly WPA3 ワークフローが毎日 20:00 JST と、取りこぼしに備えた 21:30 JST に、comma の最新コミットをもとに各ブランチを作り直します。comma が新しいビルドを出していなければ、ブランチは変えません。

特徴

• AGNOS の manifest の boot を、qcacld-3.0 Wi-Fi ドライバの SAE を有効にした boot イメージに差し替えます(commaai/agnos-kernel-sdm845#142)。このイメージは、SAE の hash-to-element(H2E)に必要な RSNXE を接続要求に載せます(#143)。system を含むほかの AGNOS イメージは comma のままで、AGNOS_VERSION も変えません。comma の元の manifest は、agnos.stock.json として隣に残します
• UI はドライバが SAE に対応していれば、WPA3 専用のネットワークを一覧に表示し、sae のプロファイルで接続します
• 修正版の wpa_supplicant を wpa3/ に同梱し、AGNOS の純正の代わりに動かします。H2E を有効にし、SAE の脆弱性修正も入っています(commaai/agnos-builder#629)。AP が H2E を広告していれば、SAE で H2E を使います。NetworkManager の動作は変わらず、WPA2/WPA3 混在のネットワークとホットスポットは WPA2-PSK のままです
• ランチャーは起動のたびに、純正のバイナリがそのビルド用に記録した SHA-256 と一致し、修正版が起動でき、その端末で以前に失敗していない場合に限って、修正版を /usr/sbin/wpa_supplicant に bind mount してサービスを再起動します。15 秒以内に修正版が動いていなければ純正に戻し、起動時の失敗 1 回、または異常終了 3 回で、その端末では差し替えをやめます。system パーティションには何も書き込まないので、fork をやめて再起動すれば純正に戻ります
• 自動ビルドの wpa_supplicant は、純正バイナリが一致する場合だけ使い、失敗した端末では純正を使います。再ビルドしたバイナリには、ソース、再現性、ABI、CI などの確認が必要ですが、これらは実機テストではありません
• 起動中のカーネルに WPA3 対応のタグ(wpa3.sae=2 のようなタグで、boot イメージごとに異なります)がなければ、ランチャーが AGNOS 更新と同じ A/B の手順で WPA3 カーネルをインストールします。updated も同じ条件で、バックグラウンドでイメージを準備します
• 起動の繰り返しを防ぐため、ランチャーの試行は boot イメージのハッシュごとに 3 回までです。3 回試してもタグがなければ試行をやめて純正カーネルのまま動き続けます。この制限が役立つのは、カーネルが openpilot の起動まで進めない場合だけです。ランチャーは起動するとすぐに成功を記録するため、起動しても Wi-Fi が壊れる場合や、あとで落ちる場合は、自動では元に戻りません
• AGNOS のバージョン更新でも同じ回数を使います。起動中のカーネルにタグがなければ更新のたびに 1 回と数え、3 回を超えたらランチャーと updated は comma の manifest(agnos.stock.json)で書き込みます。すでにタグがあれば、回数を数えずに WPA3 の manifest で更新します。タグで分かるのは、カーネルが起動したことだけです
• comma のブランチは親なしのコミットなので、各ビルドはその上に新しいコミットを 1 つ作るだけで、マージはしません。ビルドは再現可能で、入力が同じなら必ず同じコミット SHA になります
• comma が AGNOS_VERSION を上げると、scripts/pins.py が、新しいバージョンに使う boot イメージを決めます。そのバージョンの手動 pin か有効な自動 pin があればそれを使い、新しい純正カーネルが既存の pin の元になった純正カーネルと同じで agnos.py も変わっていなければ、その pin の WPA3 boot イメージを使い回します。このとき使い回すのは別の AGNOS system イメージ用のカーネルで、元のカーネルが確認済みでも、新しい組み合わせ自体は実機で確認していません。純正カーネルがすでに SAE と RSNXE(H2E)に対応していれば、boot イメージは差し替えず、UI のパッチと wpa_supplicant の差し替えは続けます。それ以外の場合、カーネルの自動公開が有効なら自動ビルドを要求して保留中(pending)にし、有効でなければ手動の pin ができるまで公開を止めます
• 所有者が WPA3_FOLLOW_MODE を off → dryrun → state → on の順に切り替えます。on では、release-tizi-staging を含む 4 ブランチすべてが、同じ実行で新しい自動 pin を採用します。自動リリースは prerelease として実機テストなしで公開し、GitHub の latest にはしません。公開は自動カーネル 7 日に 1 回まで、実機未確認のカーネルの連続は 3 回までです。各リリースの provenance.json に、pin、確認結果、ツールチェーン、基準とした実機の種類、supplicant の状態などを記録します
• 公開前に、boot イメージが決まっているか、純正の boot/system やパッチ対象が想定どおりか、boot イメージのハッシュとサイズが一致するか、公開中のビルドと比べてコマンドラインのタグと boot イメージのハッシュが 1 対 1 のままか、調べた純正 supplicant と差し替え先が一致するか、同梱の wpa_supplicant が pin の SHA-256 と一致するかなどを確認します。失敗したブランチは公開せず前回のビルドのままにし、nightly-hold ラベルの issue をブランチごとに作成または更新して知らせます
• 自動カーネルは、Actions の follow-admin の revoke で取り下げる方法を優先します。自動公開を停止し、影響する各ブランチを、同じ AGNOS 用の comma のカーネルと組み合わせて作り直します。AGNOS のダウングレードはしません
• Actions の Roll back WPA3 nightly で、選んだブランチを 1 つ前のビルドに戻せます。このとき Nightly WPA3 と自動ビルドは無効になり、4 つすべてのブランチの公開が止まります。1 つ前のビルドに戻すと、別の未確認カーネルに戻る場合や、未確認の AGNOS ダウングレードになる場合があります

対応環境と入手方法

動作確認は comma four でのみ行っています。comma 3X はカーネルとファームウェアが同じですが、未確認です。

自動ビルドのカーネルと wpa_supplicant は、実機テストなしで公開します。 CI の確認は、実機で起動・動作することを保証しません。実機で確認したのは、comma four 1 台での 2 つの AGNOS バージョンと、nightly-chestnut でのその間の移行だけで、今後の自動ビルドやほかの端末は確認していません。自動ビルドのカーネルが起動しない場合、ブートローダーは前のカーネルに戻るはずですが、これを確認したのも comma four 1 台だけです。fork は最大 3 回試したあと、新しい AGNOS 用の comma のカーネルを入れます。その間に約 20 回再起動することがあり、起動中に止まった場合は電源を入れ直す必要があります。ほかに使えるネットワークがない端末は取り下げの更新を受け取れません。復旧にはパソコンと flash.comma.ai が必要になることがあります。

インストール URL はブランチごとに次のとおりです。chestnut を使わない comma four では nightly を使ってください。

https://installer.comma.ai/shunnag/nightly
https://installer.comma.ai/shunnag/nightly-chestnut
https://installer.comma.ai/shunnag/release-mici-staging
https://installer.comma.ai/shunnag/release-tizi-staging

nightly の 2 つのブランチは、ソースも WPA3 の変更も同じです。nightly-chestnut には、chestnut 用の大きな運転モデル(約 773 MB、Hugging Face の LFS から取得)と、panda のデバッグビルド(PANDA_DEBUG_BUILD=1)が加わります。どちらも開発中の最新ブランチなので、安定性は期待しないでください。

release-mici-staging(comma four 向け)と release-tizi-staging(comma 3X 向け)は、どの実機でもテストしていません。まだ誰も動かしたことがありません。 これらは comma の release-staging の AGNOS に、別の AGNOS 用に作った WPA3 boot イメージを組み合わせたものです。この boot イメージを実機で確認したのは、nightly-chestnut を動かした comma four 1 台だけです。release-staging の AGNOS との組み合わせ、release 用のランチャー、この fork の nightly からの切り替えは、どれも未確認です。comma 3X では、WPA3 カーネルを一度も起動していません。 端末で動かなかった場合、復旧にはパソコンと flash.comma.ai が必要になることがあります。これらのビルドは comma のレビューもテストも受けていません。問題があっても comma に報告しないでください。

初回のインストールには、WPA3 専用ではないネットワークが必要です。 AGNOS のセットアップ画面と純正カーネルは WPA3 専用のネットワークにつながらないため、WPA2、WPA2/WPA3 混在モード、スマートフォンのテザリング、LTE のいずれかを用意してください。インストール後、通常の A/B 方式の AGNOS 更新で WPA3 カーネルを書き込みます。このとき約 1 GB をダウンロードすることがあります。再起動後は、WPA3 専用のネットワークも使えます。

comma の openpilot に戻すには、comma の URL から入れ直します。openpilot はバージョンが変わったときにしか AGNOS を書き直さないため、WPA3 カーネルは comma が次に AGNOS のバージョンを上げるまで残ります。すぐに消したい場合は、flash.comma.ai で AGNOS を書き直してください。

公開の準備や保守、ローカルでの検証手順は README を参照してください。