diff mbox series

[BlueZ,v1,1/3] doc: Add Advertisement Monitor Device Tracking event

Message ID 20210927131456.BlueZ.v1.1.I7f6bdb9282c1e12ffc6c662674678f2b1cb69182@changeid (mailing list archive)
State New, archived
Headers show
Series Introduce Advertisement Monitor Device Tracking event | expand

Checks

Context Check Description
tedd_an/checkpatch success Checkpatch PASS
tedd_an/gitlint success Gitlint PASS
tedd_an/setupell success Setup ELL PASS
tedd_an/buildprep success Build Prep PASS
tedd_an/build success Build Configuration PASS
tedd_an/makecheck success Make Check PASS
tedd_an/makedistcheck success Make Distcheck PASS
tedd_an/build_extell success Build External ELL PASS
tedd_an/build_extell_make success Build Make with External ELL PASS

Commit Message

Manish Mandlik Sept. 27, 2021, 8:16 p.m. UTC
This patch adds the Advertisement Monitor Device Traching event. This
event indicates that the controller has stated/stopped tracking a
particular device matching one of the already added Advertisement
Monitor.

Reviewed-by: Miao-chen Chou <mcchou@google.com>
Reviewed-by: Yun-Hao Chung <howardchung@google.com>
---

 doc/mgmt-api.txt | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

Comments

Luiz Augusto von Dentz Sept. 27, 2021, 8:23 p.m. UTC | #1
Hi Manish,

On Mon, Sep 27, 2021 at 1:17 PM Manish Mandlik <mmandlik@google.com> wrote:
>
> This patch adds the Advertisement Monitor Device Traching event. This
> event indicates that the controller has stated/stopped tracking a
> particular device matching one of the already added Advertisement
> Monitor.
>
> Reviewed-by: Miao-chen Chou <mcchou@google.com>
> Reviewed-by: Yun-Hao Chung <howardchung@google.com>
> ---
>
>  doc/mgmt-api.txt | 27 ++++++++++++++++++++++++++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 5355fedb0..06df3e914 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 Tracking event.
>
>
>  Example
> @@ -4910,3 +4911,27 @@ 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 Tracking Event
> +===========================================
> +
> +       Event code:             0x002f
> +       Controller Index:       <controller_id>
> +       Event Parameters:       Monitor_Handle (2 octets)
> +                               Monitor_State (1 octet)
> +                               Address (6 octets)
> +                               Address_Type (1 octet)
> +
> +       This event indicates that the controller has started/stopped tracking
> +       a particular device matching the Advertisement Monitor with handle
> +       Monitor_Handle.
> +
> +       Possible values for the Monitor_State parameter:
> +               0       The controller has stopped tracking a device
> +               1       The controller has started tracking a device
> +
> +       The address of the device being tracked will be shared in Address and
> +       Address_Type.
> +
> +       This event will be sent to all management sockets.

I wonder if wouldn't it be better to indicate this over Device Found?
Or the controller will indicate the advertising report in addition to
this event? Btw, I think it is about time we introduce these commands
to the emulator in order to have proper CI tests, without it cannot
become a stable API.

> --
> 2.33.0.685.g46640cef36-goog
>
bluez.test.bot@gmail.com Sept. 27, 2021, 8:38 p.m. UTC | #2
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=553715

---Test result---

Test Summary:
CheckPatch                    PASS      4.10 seconds
GitLint                       PASS      2.72 seconds
Prep - Setup ELL              PASS      50.41 seconds
Build - Prep                  PASS      0.47 seconds
Build - Configure             PASS      9.43 seconds
Build - Make                  PASS      219.41 seconds
Make Check                    PASS      9.73 seconds
Make Distcheck                PASS      263.95 seconds
Build w/ext ELL - Configure   PASS      9.43 seconds
Build w/ext ELL - Make        PASS      203.37 seconds



---
Regards,
Linux Bluetooth
Marcel Holtmann Sept. 28, 2021, 8:09 a.m. UTC | #3
Hi Manish,

> This patch adds the Advertisement Monitor Device Traching event. This
> event indicates that the controller has stated/stopped tracking a
> particular device matching one of the already added Advertisement
> Monitor.
> 
> Reviewed-by: Miao-chen Chou <mcchou@google.com>
> Reviewed-by: Yun-Hao Chung <howardchung@google.com>
> ---
> 
> doc/mgmt-api.txt | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index 5355fedb0..06df3e914 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 Tracking event.
> 
> 
> Example
> @@ -4910,3 +4911,27 @@ 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 Tracking Event
> +===========================================
> +
> +	Event code:		0x002f
> +	Controller Index:	<controller_id>
> +	Event Parameters:	Monitor_Handle (2 octets)
> +				Monitor_State (1 octet)
> +				Address (6 octets)
> +				Address_Type (1 octet)
> +
> +	This event indicates that the controller has started/stopped tracking
> +	a particular device matching the Advertisement Monitor with handle
> +	Monitor_Handle.
> +
> +	Possible values for the Monitor_State parameter:
> +		0	The controller has stopped tracking a device
> +		1	The controller has started tracking a device
> +
> +	The address of the device being tracked will be shared in Address and
> +	Address_Type.
> +
> +	This event will be sent to all management sockets.

I have to echo Luiz's comment here. How is this suppose to work. We now get a Device Found and Device Tracked event?

Wouldn’t it be really better to have a “I am tracked” flag in the Device Found event?

Regards

Marcel
Marcel Holtmann Sept. 29, 2021, 1:26 p.m. UTC | #4
Hi Manish,

can we please stop top-posting and follow the general rules of this mailing list.

> The controller sends advertising reports in addition to this event. This event is reported only when there are active and matched advertisement monitors. 
> 
> Whenever an advertisement matches a Monitor, the controller sends this event with Monitor_state set to 1, indicating that it has started monitoring that particular device. After that it may send one or more advertising reports based on the configured Sampling_period for that Monitor. Once the controller stops monitoring that device, it sends the same event again with Monitor_state set to 0 to notify the host that it has stopped monitoring that particular device.
> 
> Since this event is sent only twice (at start and end of monitoring) per monitoring period [1], combining this with the Sampling_period - 0xFF (send only one advertisement report per monitoring period) [2], we can drastically reduce the number of events generated by the controller during background scanning but still have the DeviceFound/DeviceLost functionality in bluetoothd.
> 
> So, it will be better to keep this event separate than the Device Found event as it is triggered only during monitoring. Please let me know what you think about this.
> [1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands-and-events#hci_vs_msft_le_monitor_device_event
> [2]: https://docs.microsoft.com/en-us/windows-hardware/drivers/bluetooth/microsoft-defined-bluetooth-hci-commands-and-events#hci_vs_msft_le_monitor_advertisement

This is what I was thinking:

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 97d33e30a15d..fa9121c3bc87 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -4263,6 +4263,7 @@ Device Found Event
                1       Legacy Pairing
                2       Not Connectable
                3       Reserved (not in use)
+               4       Device Tracked
 
        For the RSSI field a value of 127 indicates that the RSSI is
        not available. That can happen with Bluetooth 1.1 and earlier
@@ -4910,3 +4911,19 @@ Controller Resume Event
        Address_Type. Otherwise, Address and Address_Type will both be zero.
 
        This event will be sent to all management sockets.
+
+Device Lost Event
+=================
+
+       Event Code:             0x002f
+       Controller Index:       <controller id>
+       Event Parameters:       Address (6 Octets)
+                               Address_Type (1 Octet)
+
+       This event indicates that a tracked device was no longer found
+       during monitoring.
+
+       Possible values for the Address_Type parameter:
+               0       BR/EDR
+               1       LE Public
+               2       LE Random

I really don’t get why we would make it more complicated for mgmt-api and thus bluetoothd.

Regards

Marcel
diff mbox series

Patch

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 5355fedb0..06df3e914 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 Tracking event.
 
 
 Example
@@ -4910,3 +4911,27 @@  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 Tracking Event
+===========================================
+
+	Event code:		0x002f
+	Controller Index:	<controller_id>
+	Event Parameters:	Monitor_Handle (2 octets)
+				Monitor_State (1 octet)
+				Address (6 octets)
+				Address_Type (1 octet)
+
+	This event indicates that the controller has started/stopped tracking
+	a particular device matching the Advertisement Monitor with handle
+	Monitor_Handle.
+
+	Possible values for the Monitor_State parameter:
+		0	The controller has stopped tracking a device
+		1	The controller has started tracking a device
+
+	The address of the device being tracked will be shared in Address and
+	Address_Type.
+
+	This event will be sent to all management sockets.