[Bug 248024] Bluetooth L2CAP socket should not use automatically flushable PDUs (on LE at least)

[bugzilla-noreply at freebsd.org]

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: bugs at FreeBSD.org
          Reporter: greg at unrelenting.technology

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.