Bug 248024

Summary:	Bluetooth L2CAP socket should not use automatically flushable PDUs (on LE at least)
Product:	Base System	Reporter:	Val Packett <val>
Component:	kern	Assignee:	freebsd-wireless (Nobody) <wireless>
Status:	Closed FIXED
Severity:	Affects Only Me	CC:	emaste, emax, takawata
Priority:	---
Version:	CURRENT
Hardware:	Any
OS:	Any
See Also:	https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248015

Description Val Packett 2020-07-16 18:50:36 UTC

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?

Comment 1 Takanori Watanabe freebsd_committer

2020-07-17 10:42:08 UTC

(In reply to Greg V from comment #0)
Thank You!
My long unresolved problem is resolved! 
Now Bluetooth LE connection work with my Intel Wifi bluetooth interface.

https://reviews.freebsd.org/D25704

Comment 2 Val Packett 2020-07-17 11:43:23 UTC

(In reply to Takanori Watanabe from comment #1)

huh, which controllers *did* work with the wrong bit?

The USB dongles I have — all 0a12:0001, but two are recognized as "CSR8510" (and don't support random addresses), while another newer one (marked "v5.0", supports random addresses but doesn't like the set encryption command for some reason) is "USB1.1-A" — needed this fix..

Comment 3 Takanori Watanabe freebsd_committer

2020-07-17 15:34:28 UTC

(In reply to Greg V from comment #2)
It worked with  Nanosira M2272 CSR8510 dongle.
Newer firmware may evaluate it.

Comment 4 commit-hook freebsd_committer

2020-07-17 15:50:54 UTC

A commit references this bug:

Author: takawata
Date: Fri Jul 17 15:50:04 UTC 2020
New revision: 363276
URL: https://svnweb.freebsd.org/changeset/base/363276

Log:
  Fix L2CAP ACL packet PB(Packet Boundary) flag for LE PDU.

  ACL packet boundary flag should be 0 instead of 2 for LE PDU.
  Some HCI will drop LE packet with PB flag is 2, and if sent,
  some target may reject the packet.

  PR:	248024
  Reported by:	Greg V
  Reviewed by:	Greg V, emax
  Differential Revision:	https://reviews.freebsd.org/D25704

Changes:
  head/sys/netgraph/bluetooth/include/ng_hci.h
  head/sys/netgraph/bluetooth/l2cap/ng_l2cap_llpi.c