[Bluez PATCH v2 0/3] Bluetooth: Fix scannable broadcast advertising on extended APIs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Maintainers,

We have discovered that when userspace registers a broadcast
(non-connectable) advertisement with scan response data, it exposes a
limitation in the new extended MGMT APIs. At the time that the
parameters are registered with the controller, kernel does not yet have
the advertising data and scan response (coming in a separate MGMT call),
and will default to a non-scannable PDU. When the MGMT call for
data/scan response is received, the controller will either fail when we
request to set the scan response, or return success and not use it.

This series along with another in kernel will allow userspace to pass a
flag with the params request indicating if the advertisement contains a
scan response. This allows kernel to register the parameters correctly
with the controller.

The patch is tested with a scannable broadcast advertisement on Hatch
and Kukui chromebooks (ext and non-ext capabilities) and ensuring a
peripheral device can detect the scan response.

Best,
Daniel

Changes in v2:
- Check kernel supports flag before setting it

Daniel Winkler (3):
  advertising: Generate advertising data earlier in pipeline
  advertising: Create and use scannable adv param flag
  doc/mgmt-api: Update documentation for scan_rsp param flag

 doc/mgmt-api.txt  |  5 +++
 lib/mgmt.h        |  1 +
 src/advertising.c | 87 ++++++++++++++++++++++++++---------------------
 3 files changed, 55 insertions(+), 38 deletions(-)

-- 
2.30.1.766.gb4fecdf3b7-goog




[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux