summaryrefslogtreecommitdiff
path: root/net
diff options
context:
space:
mode:
authorDaniel Winkler <danielwinkler@google.com>2021-03-03 11:15:23 -0800
committerMarcel Holtmann <marcel@holtmann.org>2021-03-03 18:14:38 +0100
commitff02db13e9bfa01e0d66c5fa53da29bd1f1b208a (patch)
tree7b7ca51623eb72558ce72fdc128e9ce17493ab55 /net
parente5b0ad69c97a04f42834b24a6a0323ab15ccc9bb (diff)
downloadlwn-ff02db13e9bfa01e0d66c5fa53da29bd1f1b208a.tar.gz
lwn-ff02db13e9bfa01e0d66c5fa53da29bd1f1b208a.zip
Bluetooth: Allow scannable adv with extended MGMT APIs
An issue was found, where if a bluetooth client requests a broadcast advertisement with scan response data, it will not be properly registered with the controller. This is because at the time that the hci_cp_le_set_scan_param structure is created, the scan response will not yet have been received since it comes in a second MGMT call. With empty scan response, the request defaults to a non-scannable PDU type. On some controllers, the subsequent scan response request will fail due to incorrect PDU type, and others will succeed and not use the scan response. This fix allows the advertising parameters MGMT call to include a flag to let the kernel know whether a scan response will be coming, so that the correct PDU type is used in the first place. A bluetoothd change is also incoming to take advantage of it. To test this, I created a broadcast advertisement with scan response data and registered it on the hatch chromebook. Without this change, the request fails, and with it will succeed. Reviewed-by: Alain Michaud <alainm@chromium.org> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Signed-off-by: Daniel Winkler <danielwinkler@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Diffstat (limited to 'net')
-rw-r--r--net/bluetooth/hci_request.c3
-rw-r--r--net/bluetooth/mgmt.c1
2 files changed, 3 insertions, 1 deletions
diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c
index 75a42178c82d..d7ee11ef70d3 100644
--- a/net/bluetooth/hci_request.c
+++ b/net/bluetooth/hci_request.c
@@ -2180,7 +2180,8 @@ int __hci_req_setup_ext_adv_instance(struct hci_request *req, u8 instance)
cp.evt_properties = cpu_to_le16(LE_EXT_ADV_CONN_IND);
else
cp.evt_properties = cpu_to_le16(LE_LEGACY_ADV_IND);
- } else if (adv_instance_is_scannable(hdev, instance)) {
+ } else if (adv_instance_is_scannable(hdev, instance) ||
+ (flags & MGMT_ADV_PARAM_SCAN_RSP)) {
if (secondary_adv)
cp.evt_properties = cpu_to_le16(LE_EXT_ADV_SCAN_IND);
else
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 74971b4bd457..90334ac4a135 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -7432,6 +7432,7 @@ static u32 get_supported_adv_flags(struct hci_dev *hdev)
flags |= MGMT_ADV_PARAM_TIMEOUT;
flags |= MGMT_ADV_PARAM_INTERVALS;
flags |= MGMT_ADV_PARAM_TX_POWER;
+ flags |= MGMT_ADV_PARAM_SCAN_RSP;
/* In extended adv TX_POWER returned from Set Adv Param
* will be always valid.