BLE notifications get silently truncated when the negotiated MTU is too small
メンテナーはふだん 1 日以内に返信
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 55/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- flutter, rust
調査の方向性
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.
索引モデルが issue の本文から書いたものです。
説明
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::assembleintrouble-host-0.6.0/src/gatt.rs:644). Sonotify(...)attransport.rs:666reports 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() - 3and 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.
- 主要言語
- Rust
- スター
- 1
- フォーク
- 0
- 平均マージ
- 13時間 37分
- マージ済み PR（30日）
- 8
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
OpenCarControls/firmware のほかの issue
-
Refresh stale docsオープン
難易度 1/5 1〜3時間 初心者へのやさしさ 67/100
OpenCarControls/firmware#35 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
OpenCarControls/firmware#34 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
OpenCarControls/firmware#31 ·
メンテナーはふだん 1 日以内に返信
-
good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
OpenCarControls/firmware#30 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
OpenCarControls/firmware#57 ·
メンテナーはふだん 1 日以内に返信
OpenCarControls/firmware の issue をすべて見る
似ている issue
-
state:triage-needed
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
bug P2
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
pedrovgs/UseCaseCoverage#23 ·
-
area: library data-loss tier: p0 type: bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 1 日以内に返信
-
llm translation
難易度 1/5 1時間未満 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信