https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248024
Bug ID: 248024
Summary: Bluetooth L2CAP socket should not use automatically
flushable PDUs (on LE at least)
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
So I've been debugging why a certain BLE device
(https://github.com/open-homeautomation/miflora) did not respond to my commands
on FreeBSD.
(bug 248015 for the ability to talk ACL via raw HCI socket was needed for that
debugging.)
Replaying the ACL packet Linux was sending via the raw HCI socket I do get
replies. Sending its L2CAP payload via an L2CAP socket.. no reply. Difference?
One bit:
(good) 02 00 00 0b 00 07 00 04 00 10 01 00 ff ff 00 28
(bad) 02 00 20 0b 00 07 00 04 00 10 01 00 ff ff 00 28
^ that's the PB flag set to 2!
So turns out ng_l2cap_lp_send does `flag = NG_HCI_PACKET_START`.
But our NG_HCI_PACKET_START (2) doesn't just mean "packet start"!
According to the Bluetooth Core Spec v5.2 (Vol 4, Part E, 5.4.2, page 1893) it
means "First automatically flushable packet of a higher layer message (start of
an automatically flushable L2CAP PDU)" and it's *not allowed for LE*!
The laziest solution would be `flag = 0`, where 0 means "First
non-automatically-flushable packet of a higher layer message (start of a
non-automatically-flushable L2CAP PDU) from Host to Controller".
But then there's the question: is there any benefit from the automatic flushing
thing on Bluetooth Classic?? Maybe we should only use 0 on LE?
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
