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

BLE notifications get silently truncated when the negotiated MTU is too small

Chiusa
  • Qualcosa non va?
#28 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #52 di @Tichael — integrata

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
flutter, rust
Ambito
embedded-iot, mobile-dev

Direzione di ricerca

Start with the BLE TX task in boards/esp/src/ble/transport.rs around lines 638 and 666, then check how trouble-host handles notifications in gatt::assemble and how the mobile app handles the requested MTU in mobile-app/lib/providers/ble_connection_provider.dart. The issue suggests waiting for the MTU exchange event and checking each payload against the negotiated MTU; done means oversized messages are never silently truncated and a small MTU is logged on both sides.

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

Descrizione

Problem
BLE messages aren't fragmented: every message must fit in one ATT packet, at most ble.payload.max_message_bytes (244 bytes, from an ATT MTU of 247). The firmware never checks the MTU that was actually negotiated:

  • After the link is encrypted, the TX task sleeps 500 ms and assumes the MTU exchange is done by then (boards/esp/src/ble/transport.rs:638). Nothing confirms it.
  • trouble-host 0.6 trims a notification to the connection's ATT MTU without returning an error (gatt::assemble in trouble-host-0.6.0/src/gatt.rs:644). So notify(...) at transport.rs:666 reports success while the app receives a cut-off protobuf it can't decode.
  • The app requests kBleAttMtu (mobile-app/lib/providers/ble_connection_provider.dart:219). When it gets less, it only logs a warning.

When it happens
The MTU exchange takes longer than 500 ms, or the phone negotiates less than 247. Some Android phones do; iOS picks its own MTU, which matters if iOS is ever supported. State updates near the worst-case size are then lost silently.

Ideas

  • Wait for the MTU-exchange event instead of sleeping.
  • Before each notify, compare the payload with conn.raw().att_mtu() - 3 and drop or log anything that doesn't fit, rather than sending a truncated message.
  • Longer term: BLE fragmentation (https://github.com/OpenCarControls/contracts/issues/5) removes the limit.

Done when
No message is ever sent truncated, and an MTU that's too small is visible in the logs on both sides.

Lingua principale
Rust
Stelle
1
Fork
0
Merge medio
10h 56m
PR unite (30g)
15

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.