Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#70 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
embedded-iot

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Rust
Stars
1
Forks
0
Avg merge
14h 32m
Merged PRs (30d)
21

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenCarControls/firmware

All issues in OpenCarControls/firmware

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.