Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jul 2020 18:50:36 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 248024] Bluetooth L2CAP socket should not use automatically flushable PDUs (on LE at least)
Message-ID:  <bug-248024-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248024

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

So I've been debugging why a certain BLE device
(https://github.com/open-homeautomation/miflora) did not respond to my comm=
ands
on FreeBSD.
(bug 248015 for the ability to talk ACL via raw HCI socket was needed for t=
hat
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. Differen=
ce?
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 =3D 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 (star=
t of
an automatically flushable L2CAP PDU)" and it's *not allowed for LE*!

The laziest solution would be `flag =3D 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 flus=
hing
thing on Bluetooth Classic?? Maybe we should only use 0 on LE?

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248024-227>