Hello Bt-Maintainers,
Bluetooth Advertisement Monitor API was introduced to support background
scanning and proximity detection based on the application specified RSSI
thresholds and content filters on LE advertisement packets.
To optimize the power consumption, the API offloads the content
filtering and RSSI tracking to the controller if the controller
offloading support is available. However, this monitoring is not
completely offloaded as the bluetoothd also handles RSSI thresholds and
timeouts in order to fulfill high/low thresholds/timeouts filtering with
D-bus clients.
There is further room to achieve better power optimization by supporting
the controller event HCI_VS_MSFT_LE_Monitor_Device_Event to fulfill true
monitor offloading. This is currently not supported as it was originally
desired to minimize the changes to the MGMT interface and reuse the
existing MGMT event - MGMT_EV_DEVICE_FOUND to pass advertisements to
bluetoothd and let bluetoothd handle the RSSI thresholds and timeouts in
order to fulfill the D-bus API requirements for the client.
This patch introduces a new MGMT event 'Device Lost' to indicate that
the controller has stopped tracking a particular device. There is no
need to send another event when the controller starts tracking a device
as 'Device Found' event is sent anyway.
Please let me know what you think about this or if you have any further
questions.
Thanks,
Manish.
Changes in v3:
- Discard changes to the Device Found event and notify bluetoothd only
when the controller stops monitoring the device via new Device Lost
event.
- Discard changes to the Device Found event and notify bluetoothd only
when the controller stops monitoring the device via new Device Lost
event.
- Fix indentation of the adv_monitor_device_lost_callback() name and
it's arguments.
Changes in v2:
- Instead of creating a new 'Device Tracking' event, add a flag 'Device
Tracked' in the existing 'Device Found' event and add a new 'Device
Lost' event to indicate that the controller has stopped tracking that
device.
- Instead of creating a new 'Device Tracking' event, add a flag 'Device
Tracked' in the existing 'Device Found' event and add a new 'Device
Lost' event to indicate that the controller has stopped tracking that
device.
- Update function name adv_monitor_tracking_callback() to
adv_monitor_device_lost_callback() as it will receive only Device Lost
event.
Manish Mandlik (3):
doc: Introduce the Adv Monitor Device Lost event
lib: Add definition of the Adv Monitor Device Lost event
adv_monitor: Receive the Device Lost event
doc/mgmt-api.txt | 26 +++++++++++++++++++++++++-
lib/mgmt.h | 7 +++++++
src/adv_monitor.c | 25 +++++++++++++++++++++++++
3 files changed, 57 insertions(+), 1 deletion(-)
--
2.33.0.882.g93a45727a2-goog
This patch registers a callback function to receive Advertisement
Monitor Device Lost event.
Test performed:
- verified by logs that Monitor Device is received from the controller
and sent to the bluetoothd when the controller starts/stops monitoring
a bluetooth device.
---
Changes in v3:
- Fix indentation of the adv_monitor_device_lost_callback() name and
it's arguments.
Changes in v2:
- Update function name adv_monitor_tracking_callback() to
adv_monitor_device_lost_callback() as it will receive only Device Lost
event.
src/adv_monitor.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/src/adv_monitor.c b/src/adv_monitor.c
index 715ac5904..385ab26e6 100644
--- a/src/adv_monitor.c
+++ b/src/adv_monitor.c
@@ -1531,6 +1531,27 @@ static void adv_monitor_removed_callback(uint16_t index, uint16_t length,
ev->monitor_handle);
}
+/* Processes Adv Monitor tracking event from kernel */
+static void adv_monitor_device_lost_callback(uint16_t index, uint16_t length,
+ const void *param, void *user_data)
+{
+ struct btd_adv_monitor_manager *manager = user_data;
+ const struct mgmt_ev_adv_monitor_device_lost *ev = param;
+ uint16_t handle = le16_to_cpu(ev->monitor_handle);
+ const uint16_t adapter_id = manager->adapter_id;
+ char addr[18];
+
+ if (length < sizeof(*ev)) {
+ btd_error(adapter_id,
+ "Wrong size of Adv Monitor Device Lost event");
+ return;
+ }
+
+ ba2str(&ev->addr.bdaddr, addr);
+ DBG("Adv monitor with handle 0x%04x stopped tracking the device %s",
+ handle, addr);
+}
+
/* Allocates a manager object */
static struct btd_adv_monitor_manager *manager_new(
struct btd_adapter *adapter,
@@ -1555,6 +1576,10 @@ static struct btd_adv_monitor_manager *manager_new(
manager->adapter_id, adv_monitor_removed_callback,
manager, NULL);
+ mgmt_register(manager->mgmt, MGMT_EV_ADV_MONITOR_DEVICE_LOST,
+ manager->adapter_id, adv_monitor_device_lost_callback,
+ manager, NULL);
+
return manager;
}
--
2.33.0.882.g93a45727a2-goog
Add a new event 'Adv Monitor Device Lost' to indicate that the
controller has stopped tracking a particular device.
---
Changes in v3:
- Discard changes to the Device Found event and notify bluetoothd only
when the controller stops monitoring the device via new Device Lost
event.
Changes in v2:
- Instead of creating a new 'Device Tracking' event, add a flag 'Device
Tracked' in the existing 'Device Found' event and add a new 'Device
Lost' event to indicate that the controller has stopped tracking that
device.
doc/mgmt-api.txt | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 5355fedb0..712bb362d 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -107,7 +107,8 @@ Configuration command, Default Runtime Configuration Changed event, Get
Device Flags command, Set Device Flags command, Device Flags Changed event,
Read Advertisement Monitor Features command, Add Advertisement Patterns
Monitor command, Remove Advertisement Monitor command, Advertisement Monitor
-Added event and Advertisement Monitor Removed event.
+Added event, Advertisement Monitor Removed event and Advertisement Monitor
+Device Lost event.
Example
@@ -4910,3 +4911,26 @@ Controller Resume Event
Address_Type. Otherwise, Address and Address_Type will both be zero.
This event will be sent to all management sockets.
+
+
+Advertisement Monitor Device Lost Event
+=======================================
+
+ Event code: 0x002f
+ Controller Index: <controller_id>
+ Event Parameters: Monitor_Handle (2 Octets)
+ Address (6 Octets)
+ Address_Type (1 Octet)
+
+ This event indicates that the controller has stopped tracking the
+ device that was being tracked by monitor with handle Monitor_Handle.
+
+ The address of the device being tracked will be shared in Address and
+ Address_Type.
+
+ Possible values for the Address_Type parameter:
+ 0 BR/EDR
+ 1 LE Public
+ 2 LE Random
+
+ This event will be sent to all management sockets.
--
2.33.0.882.g93a45727a2-goog
This is automated email and please do not reply to this email!
Dear submitter,
Thank you for submitting the patches to the linux bluetooth mailing list.
This is a CI test results with your patch series:
PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=562967
---Test result---
Test Summary:
CheckPatch PASS 1.30 seconds
GitLint PASS 0.85 seconds
Prep - Setup ELL PASS 48.42 seconds
Build - Prep PASS 0.25 seconds
Build - Configure PASS 8.57 seconds
Build - Make PASS 202.56 seconds
Make Check PASS 9.36 seconds
Make Distcheck PASS 243.99 seconds
Build w/ext ELL - Configure PASS 8.72 seconds
Build w/ext ELL - Make PASS 191.73 seconds
---
Regards,
Linux Bluetooth
Hi Manish,
On Wed, Oct 13, 2021 at 12:00 PM Manish Mandlik <[email protected]> wrote:
>
> Add a new event 'Adv Monitor Device Lost' to indicate that the
> controller has stopped tracking a particular device.
>
> ---
>
> Changes in v3:
> - Discard changes to the Device Found event and notify bluetoothd only
> when the controller stops monitoring the device via new Device Lost
> event.
>
> Changes in v2:
> - Instead of creating a new 'Device Tracking' event, add a flag 'Device
> Tracked' in the existing 'Device Found' event and add a new 'Device
> Lost' event to indicate that the controller has stopped tracking that
> device.
>
> doc/mgmt-api.txt | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 5355fedb0..712bb362d 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -107,7 +107,8 @@ Configuration command, Default Runtime Configuration Changed event, Get
> Device Flags command, Set Device Flags command, Device Flags Changed event,
> Read Advertisement Monitor Features command, Add Advertisement Patterns
> Monitor command, Remove Advertisement Monitor command, Advertisement Monitor
> -Added event and Advertisement Monitor Removed event.
> +Added event, Advertisement Monitor Removed event and Advertisement Monitor
> +Device Lost event.
>
>
> Example
> @@ -4910,3 +4911,26 @@ Controller Resume Event
> Address_Type. Otherwise, Address and Address_Type will both be zero.
>
> This event will be sent to all management sockets.
> +
> +
> +Advertisement Monitor Device Lost Event
> +=======================================
> +
> + Event code: 0x002f
> + Controller Index: <controller_id>
> + Event Parameters: Monitor_Handle (2 Octets)
> + Address (6 Octets)
> + Address_Type (1 Octet)
> +
> + This event indicates that the controller has stopped tracking the
> + device that was being tracked by monitor with handle Monitor_Handle.
> +
> + The address of the device being tracked will be shared in Address and
> + Address_Type.
> +
> + Possible values for the Address_Type parameter:
> + 0 BR/EDR
Can the address really be BR/EDR? I always assumed adv monitor to be
LE only, or am I mistaken?
> + 1 LE Public
> + 2 LE Random
> +
> + This event will be sent to all management sockets.
> --
> 2.33.0.882.g93a45727a2-goog
>
--
Luiz Augusto von Dentz
Hi Manish,
On Wed, Oct 13, 2021 at 12:00 PM Manish Mandlik <[email protected]> wrote:
>
> This patch registers a callback function to receive Advertisement
> Monitor Device Lost event.
>
> Test performed:
> - verified by logs that Monitor Device is received from the controller
> and sent to the bluetoothd when the controller starts/stops monitoring
> a bluetooth device.
>
> ---
>
> Changes in v3:
> - Fix indentation of the adv_monitor_device_lost_callback() name and
> it's arguments.
>
> Changes in v2:
> - Update function name adv_monitor_tracking_callback() to
> adv_monitor_device_lost_callback() as it will receive only Device Lost
> event.
>
> src/adv_monitor.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/src/adv_monitor.c b/src/adv_monitor.c
> index 715ac5904..385ab26e6 100644
> --- a/src/adv_monitor.c
> +++ b/src/adv_monitor.c
> @@ -1531,6 +1531,27 @@ static void adv_monitor_removed_callback(uint16_t index, uint16_t length,
> ev->monitor_handle);
> }
>
> +/* Processes Adv Monitor tracking event from kernel */
> +static void adv_monitor_device_lost_callback(uint16_t index, uint16_t length,
> + const void *param, void *user_data)
> +{
> + struct btd_adv_monitor_manager *manager = user_data;
> + const struct mgmt_ev_adv_monitor_device_lost *ev = param;
> + uint16_t handle = le16_to_cpu(ev->monitor_handle);
> + const uint16_t adapter_id = manager->adapter_id;
> + char addr[18];
> +
> + if (length < sizeof(*ev)) {
> + btd_error(adapter_id,
> + "Wrong size of Adv Monitor Device Lost event");
> + return;
> + }
> +
> + ba2str(&ev->addr.bdaddr, addr);
> + DBG("Adv monitor with handle 0x%04x stopped tracking the device %s",
> + handle, addr);
Isn't there a DeviceLost in the AdvertisementMonitor1 interface?
Otherwise this is quite pointless since the only thing it is doing is
printing the event without taking any action.
> +}
> +
> /* Allocates a manager object */
> static struct btd_adv_monitor_manager *manager_new(
> struct btd_adapter *adapter,
> @@ -1555,6 +1576,10 @@ static struct btd_adv_monitor_manager *manager_new(
> manager->adapter_id, adv_monitor_removed_callback,
> manager, NULL);
>
> + mgmt_register(manager->mgmt, MGMT_EV_ADV_MONITOR_DEVICE_LOST,
> + manager->adapter_id, adv_monitor_device_lost_callback,
> + manager, NULL);
> +
> return manager;
> }
>
> --
> 2.33.0.882.g93a45727a2-goog
>
--
Luiz Augusto von Dentz
Hi Manish,
> Add a new event 'Adv Monitor Device Lost' to indicate that the
> controller has stopped tracking a particular device.
>
> ---
>
> Changes in v3:
> - Discard changes to the Device Found event and notify bluetoothd only
> when the controller stops monitoring the device via new Device Lost
> event.
>
> Changes in v2:
> - Instead of creating a new 'Device Tracking' event, add a flag 'Device
> Tracked' in the existing 'Device Found' event and add a new 'Device
> Lost' event to indicate that the controller has stopped tracking that
> device.
>
> doc/mgmt-api.txt | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 5355fedb0..712bb362d 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -107,7 +107,8 @@ Configuration command, Default Runtime Configuration Changed event, Get
> Device Flags command, Set Device Flags command, Device Flags Changed event,
> Read Advertisement Monitor Features command, Add Advertisement Patterns
> Monitor command, Remove Advertisement Monitor command, Advertisement Monitor
> -Added event and Advertisement Monitor Removed event.
> +Added event, Advertisement Monitor Removed event and Advertisement Monitor
> +Device Lost event.
>
>
> Example
> @@ -4910,3 +4911,26 @@ Controller Resume Event
> Address_Type. Otherwise, Address and Address_Type will both be zero.
>
> This event will be sent to all management sockets.
I would consider adding a Advertising Monitor Device Found Event that is similar to the Device Found event, but also includes the Monitor_Handle. It just makes this whole thing a bit more symmetric.
> +
> +
> +Advertisement Monitor Device Lost Event
> +=======================================
> +
> + Event code: 0x002f
> + Controller Index: <controller_id>
> + Event Parameters: Monitor_Handle (2 Octets)
> + Address (6 Octets)
> + Address_Type (1 Octet)
> +
> + This event indicates that the controller has stopped tracking the
> + device that was being tracked by monitor with handle Monitor_Handle.
> +
> + The address of the device being tracked will be shared in Address and
> + Address_Type.
> +
> + Possible values for the Address_Type parameter:
> + 0 BR/EDR
> + 1 LE Public
> + 2 LE Random
> +
> + This event will be sent to all management sockets.
And as noted by Luiz, make 0 Reserved since we only do this for LE at the moment.
Regards
Marcel