Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đã đóng
  • Có gì không ổn?
#28 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Một pull request liên quan đã được merge.

  • #52 của @Tichael — đã merge

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
flutter, rust
Lĩnh vực
embedded-iot, mobile-dev

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Rust
Star
1
Fork
0
Merge trung bình
14 giờ 32 phút
Pull request đã merge (30 ngày)
21

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

  • Không có Dockerfile hay tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của OpenCarControls/firmware

Tất cả issue của OpenCarControls/firmware

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.