BLE: connection right after boot sees the first-setup pairing window as closed
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 55/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- rust
- 領域
- embedded-iot
調査の方向性
Start by tracing the boot-time pairing-window setup and the BLE advertise and connection handling paths; the issue does not name files or tests. Reproduce the reported sequence with no stored bonds and an immediate connection, then check that a connection after the window-open log sees pairing_window=true or that advertising begins only after the window is open.
索引モデルが issue の本文から書いたものです。
説明
Problem
Right after boot, a phone that connects while the first-setup pairing window should already be open is handled as if the window were closed, and gets dropped as an unknown peer.
Seen
WiCAN (ESP32-C3), main @ 118c5e7, virtual-car, flash just erased (0 bonds), on 2026-10-24 while hardware-testing OpenCarControls/mobile-app#47:
17:12:31.762 INFO - BLE store: loaded 0 bond(s)
17:12:31.767 INFO - BLE transport: GATT host initialised, starting advertise loop
17:12:31.783 INFO - No pairing button defined and no phone bonded; BLE pairing window opened for 60s on boot
17:12:31.970 INFO - BLE transport: central connected peer=[02, 16, 70, E4, B2, 6A] (pairing_window=false)
17:12:31.973 INFO - BLE gatt: peer [02, 16, 70, E4, B2, 6A] connected — is_known=false pairing_open=false
17:12:31.975 INFO - BLE: disconnecting unknown peer — pairing window closed
The next connection, 30 s later, saw pairing_window=true as expected. The phone (Android, still holding a bond the board had lost) was retrying a direct connection, so it connected as soon as the board advertised.
Likely cause (not verified)
The advertise loop or the connection handling starts before the boot-time window state reaches it: it's logged as opened 16 ms after the advertise loop starts, and the connection 187 ms later still read it as closed. Possibly the window is opened asynchronously, through a channel or a later task, while the connection handler reads a separate flag.
Impact
Small for real pairing, since the user scans first and connects seconds later. But a phone that's already trying to reconnect can hit it right after boot, and it makes boot-time logs misleading.
Done when
A connection that arrives after pairing window opened is logged on boot sees pairing_window=true. Or the window is open before advertising starts.
- 主要言語
- Rust
- スター
- 1
- フォーク
- 0
- 平均マージ
- 15時間 26分
- マージ済み PR（30日）
- 22
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
OpenCarControls/firmware のほかの issue
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
OpenCarControls/firmware#77 ·
メンテナーはふだん 1 日以内に返信
-
e-gmp enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
OpenCarControls/firmware#75 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
OpenCarControls/firmware#74 ·
メンテナーはふだん 1 日以内に返信
-
e-gmp enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
OpenCarControls/firmware#71 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 3/5 1〜2日 初心者へのやさしさ 51/100
OpenCarControls/firmware#68 ·
メンテナーはふだん 1 日以内に返信
OpenCarControls/firmware の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
Bump rustls-webpki, webpki-roots and webpki-root-certs for the emSign distrust (CVE-2026-111943)オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 79/100
メンテナーはふだん 1 日以内に返信
-
type: enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
franciscoBSalgueiro/en-croissant#1061 ·
メンテナーはふだん 3 日以内に返信
-
chore good first issue macros spire
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信