Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

BLE: connection right after boot sees the first-setup pairing window as closed

Aperta
  • Qualcosa non va?
#70 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
embedded-iot

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

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.

Lingua principale
Rust
Stelle
1
Fork
0
Merge medio
14h 32m
PR unite (30g)
21

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di OpenCarControls/firmware

Tutte le issue di OpenCarControls/firmware

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.