* [Bluez PATCH v4 01/10] doc/advertising-api: update API with new interface
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
@ 2020-10-01 23:01 ` Daniel Winkler
2020-10-27 21:59 ` Luiz Augusto von Dentz
2020-10-01 23:01 ` [Bluez PATCH v4 02/10] doc/mgmt-api: Add new Advertising MGMT interfaces to mgmt-api Daniel Winkler
` (10 subsequent siblings)
11 siblings, 1 reply; 18+ messages in thread
From: Daniel Winkler @ 2020-10-01 23:01 UTC (permalink / raw)
To: luiz.von.dentz
Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler,
Sonny Sasaka, Alain Michaud
This updates the advertising documentation to include the following
features:
LE Advertising Manager:
- New SupportedCapabilities property
LE Advertisement:
- New min/max interval properties
- New tx power property
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
doc/advertising-api.txt | 50 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/doc/advertising-api.txt b/doc/advertising-api.txt
index b0565eab2..3215a52f7 100644
--- a/doc/advertising-api.txt
+++ b/doc/advertising-api.txt
@@ -138,6 +138,33 @@ Properties string Type
"2M"
"Coded"
+ uint32 MinInterval
+
+ Minimum advertising interval to be used by the
+ advertising set, in .625 millisecond slots.
+ Time = N * .625 ms, where N has range
+ [0x000020, 0xFFFFFF]. If the provided MinInterval is
+ larger than the provided MaxInterval, the registration
+ will return failure.
+
+ uint32 MaxInterval
+
+ Maximum advertising interval to be used by the
+ advertising set, in .625 millisecond slots.
+ Time = N * .625 ms, where N has range
+ [0x000020, 0xFFFFFF]. If the provided MinInterval is
+ larger than the provided MaxInterval, the registration
+ will return failure.
+
+ int16 TxPower
+
+ Requested transmission power of this advertising set.
+ The provided value is used only if the "CanSetTxPower"
+ feature is enabled on the Advertising Manager. The
+ provided value must be in range [-127 to +20], where
+ units are in dBm.
+
+
LE Advertising Manager hierarchy
================================
@@ -209,3 +236,26 @@ Properties byte ActiveInstances
Possible values: "1M"
"2M"
"Coded"
+
+ dict SupportedCapabilities
+
+ Enumerates Advertising-related controller capabilities
+ useful to the client.
+
+ Possible Values:
+
+ byte MaxAdvLen
+
+ Max advertising data length
+
+ byte MaxScnRspLen
+
+ Max advertising scan response length
+
+ int16 MinTxPower
+
+ Min advertising tx power (dBm)
+
+ int16 MaxTxPower
+
+ Max advertising tx power (dBm)
--
2.28.0.709.gb0816b6eb0-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [Bluez PATCH v4 01/10] doc/advertising-api: update API with new interface
2020-10-01 23:01 ` [Bluez PATCH v4 01/10] doc/advertising-api: update API with new interface Daniel Winkler
@ 2020-10-27 21:59 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 18+ messages in thread
From: Luiz Augusto von Dentz @ 2020-10-27 21:59 UTC (permalink / raw)
To: Daniel Winkler
Cc: Luiz Augusto Von Dentz, linux-bluetooth,
ChromeOS Bluetooth Upstreaming, Sonny Sasaka, Alain Michaud
Hi Daniel,
On Thu, Oct 1, 2020 at 4:07 PM Daniel Winkler <danielwinkler@google.com> wrote:
>
> This updates the advertising documentation to include the following
> features:
>
> LE Advertising Manager:
> - New SupportedCapabilities property
>
> LE Advertisement:
> - New min/max interval properties
> - New tx power property
>
> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
> Reviewed-by: Alain Michaud <alainm@chromium.org>
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> doc/advertising-api.txt | 50 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/doc/advertising-api.txt b/doc/advertising-api.txt
> index b0565eab2..3215a52f7 100644
> --- a/doc/advertising-api.txt
> +++ b/doc/advertising-api.txt
> @@ -138,6 +138,33 @@ Properties string Type
> "2M"
> "Coded"
>
> + uint32 MinInterval
> +
> + Minimum advertising interval to be used by the
> + advertising set, in .625 millisecond slots.
> + Time = N * .625 ms, where N has range
> + [0x000020, 0xFFFFFF]. If the provided MinInterval is
> + larger than the provided MaxInterval, the registration
> + will return failure.
> +
> + uint32 MaxInterval
> +
> + Maximum advertising interval to be used by the
> + advertising set, in .625 millisecond slots.
> + Time = N * .625 ms, where N has range
> + [0x000020, 0xFFFFFF]. If the provided MinInterval is
> + larger than the provided MaxInterval, the registration
> + will return failure.
> +
> + int16 TxPower
> +
> + Requested transmission power of this advertising set.
> + The provided value is used only if the "CanSetTxPower"
> + feature is enabled on the Advertising Manager. The
> + provided value must be in range [-127 to +20], where
> + units are in dBm.
> +
> +
> LE Advertising Manager hierarchy
> ================================
>
> @@ -209,3 +236,26 @@ Properties byte ActiveInstances
> Possible values: "1M"
> "2M"
> "Coded"
> +
> + dict SupportedCapabilities
> +
> + Enumerates Advertising-related controller capabilities
> + useful to the client.
> +
> + Possible Values:
> +
> + byte MaxAdvLen
> +
> + Max advertising data length
> +
> + byte MaxScnRspLen
> +
> + Max advertising scan response length
> +
> + int16 MinTxPower
> +
> + Min advertising tx power (dBm)
> +
> + int16 MaxTxPower
> +
> + Max advertising tx power (dBm)
> --
> 2.28.0.709.gb0816b6eb0-goog
Please mark these as experimental for now, other than that it looks good to me.
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bluez PATCH v4 02/10] doc/mgmt-api: Add new Advertising MGMT interfaces to mgmt-api
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
2020-10-01 23:01 ` [Bluez PATCH v4 01/10] doc/advertising-api: update API with new interface Daniel Winkler
@ 2020-10-01 23:01 ` Daniel Winkler
2020-10-01 23:01 ` [Bluez PATCH v4 03/10] doc/mgmt-api: Update controller capabilities MGMT command in mgmt-api Daniel Winkler
` (9 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Daniel Winkler @ 2020-10-01 23:01 UTC (permalink / raw)
To: luiz.von.dentz
Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler,
Sonny Sasaka, Alain Michaud
This patch adds the following to mgmt-api:
- Add Extended Advertising Parameters Command
- Add Extended Advertising Data Command
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
---
Changes in v4:
- mgmt-api: moved optional params into 'flags' field
- mgmt-api: added info for new return parameters for max data size
Changes in v3:
- Removed Tx Power Selected MGMT event
- Changed Read Security Info cmd to Read Controller Capabilities
Changes in v2:
- Removed extra space in Add Extended Advertising Parameters API
doc/mgmt-api.txt | 217 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 217 insertions(+)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index e7a713824..7c899a8fe 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -3574,6 +3574,223 @@ Remove Advertisement Monitor Command
Busy
+Add Extended Advertising Parameters Command
+===========================================
+
+ Command Code: 0x0054
+ Controller Index: <controller id>
+ Command Parameters: Instance (1 Octet)
+ Flags (4 Octets)
+ Params (2 Octets)
+ Duration (2 Octets)
+ Timeout (2 Octets)
+ MinInterval (4 Octets)
+ MaxInterval (4 Octets)
+ TxPower (1 Octet)
+ Return Parameters: Instance (1 Octet)
+ TxPower (1 Octet)
+ MaxAdvDataLen (1 Octet)
+ MaxScanRspLen (1 Octet)
+
+ This command is used to configure the parameters for Bluetooth Low
+ Energy advertising instance. This command is expected to be followed
+ by an Add Extended Advertising Data command to complete and enable
+ the advertising instance.
+
+ Added advertising information with this command will not be visible
+ immediately if advertising is enabled via the Set Advertising
+ command. The usage of the Set Advertising command takes precedence
+ over this command. Instance information is stored and will be
+ advertised once advertising via Set Advertising has been disabled.
+
+ The Instance identifier is a value between 1 and the number of
+ supported instances. The value 0 is reserved.
+
+ With the Flags value the type of advertising is controlled and
+ the following flags are defined:
+
+ 0 Switch into Connectable mode
+ 1 Advertise as Discoverable
+ 2 Advertise as Limited Discoverable
+ 3 Add Flags field to Adv_Data
+ 4 Add TX Power field to Adv_Data
+ 5 Add Appearance field to Scan_Rsp
+ 6 Add Local Name in Scan_Rsp
+ 7 Secondary Channel with LE 1M
+ 8 Secondary Channel with LE 2M
+ 9 Secondary Channel with LE Coded
+ 12 The Duration parameter should be used
+ 13 The Timeout parameter should be used
+ 14 The Interval parameters should be used
+ 15 The Tx Power parameter should be used
+
+ When the connectable flag is set, then the controller will use
+ undirected connectable advertising. The value of the connectable
+ setting can be overwritten this way. This is useful to switch a
+ controller into connectable mode only for LE operation. This is
+ similar to the mode 0x02 from the Set Advertising command.
+
+ When the connectable flag is not set, then the controller will
+ use advertising based on the connectable setting. When using
+ non-connectable or scannable advertising, the controller will
+ be programmed with a non-resolvable random address. When the
+ system is connectable, then the identity address or resolvable
+ private address will be used.
+
+ Using the connectable flag is useful for peripheral mode support
+ where BR/EDR (and/or LE) is controlled by Add Device. This allows
+ making the peripheral connectable without having to interfere
+ with the global connectable setting.
+
+ Secondary channel flags can be used to advertise in secondary
+ channel with the corresponding PHYs. These flag bits are mutually
+ exclusive and setting multiple will result in Invalid Parameter
+ error. Choosing either LE 1M or LE 2M will result in using
+ extended advertising on the primary channel with LE 1M and the
+ respectively LE 1M or LE 2M on the secondary channel. Choosing
+ LE Coded will result in using extended advertising on the primary
+ and secondary channels with LE Coded. Choosing none of these flags
+ will result in legacy advertising.
+
+ To allow future parameters to be optionally extended in this structure,
+ the flags member has been used to specify which of the structure
+ fields were purposefully set by the caller. Unspecified parameters will
+ be given sensible defaults by the kernel before the advertisement is
+ registered.
+
+ The Duration parameter configures the length of an Instance. The
+ value is in seconds. The default is 2 seconds.
+
+ If only one advertising Instance has been added, then the Duration
+ value will be ignored. It only applies for the case where multiple
+ Instances are configured. In that case every Instance will be
+ available for the Duration time and after that it switches to
+ the next one. This is a simple round-robin based approach.
+
+ The Timeout parameter configures the life-time of an Instance. In
+ case the value 0 is used it indicates no expiration time. If a
+ timeout value is provided, then the advertising Instance will be
+ automatically removed when the timeout passes. The value for the
+ timeout is in seconds. Powering down a controller will invalidate
+ all advertising Instances and it is not possible to add a new
+ Instance with a timeout when the controller is powered down.
+
+ When a Timeout is provided, then the Duration subtracts from
+ the actual Timeout value of that Instance. For example an Instance
+ with Timeout of 5 and Duration of 2 will be scheduled exactly 3
+ times, twice with 2 seconds and once with one second. Other
+ Instances have no influence on the Timeout.
+
+ MinInterval and MaxInterval define the minimum and maximum advertising
+ intervals, with units as number of .625ms advertising slots. The Max
+ interval is expected to be greater than or equal to the Min interval,
+ and both must have values in the range [0x000020, 0xFFFFFF]. If either
+ condition is not met, the registration will fail.
+
+ The provided Tx Power parameter will only be used if the controller
+ supports it, which can be determined by the presence of the
+ CanSetTxPower member of the Read Advertising Features command.
+
+ The acceptable range for requested Tx Power is defined in the spec
+ (Version 5.2 | Vol 4, Part E, page 2585) to be [-127, +20] dBm, and the
+ controller will select a power value up to the requested one. The
+ transmission power selected by the controller is not guaranteed
+ to match the requested one, so the reply will contain the power
+ chosen by the controller. If the requested Tx Power is outside
+ the valid range, the registration will fail.
+
+ Re-adding an already existing instance (i.e. issuing the Add Extended
+ Advertising Parameters command with an Instance identifier of an
+ existing instance) will update that instance's configuration. In this
+ case where no new instance is added, no Advertising Added event will
+ be generated. However, if the update of the instance fails, the
+ instance will be removed, and an Advertising Removed event will be
+ generated.
+
+ An instance being added or changed while another instance is
+ being advertised will not be visible immediately but only when
+ the new/changed instance is being scheduled by the round robin
+ advertising algorithm.
+
+ Changes to an instance that is currently being advertised will
+ cancel that instance and switch to the next instance. The changes
+ will be visible the next time the instance is scheduled for
+ advertising. In case a single instance is active, this means
+ that changes will be visible right away.
+
+ The MaxAdvDataLen return parameter indicates how large the data
+ payload can be in the subsequent Add Extended Advertising Data
+ Command, as it accounts for the data required for the selected flags.
+ Similarly, the MaxScanRspLen return parameter indicates how large
+ the scan response can be.
+
+ LE must already be enabled, and the controller must be powered,
+ otherwise a "rejected" status will be returned.
+
+ This command generates a Command Complete event on success or a
+ Command Status event on failure.
+
+ Possible errors: Failed
+ Rejected
+ Not Supported
+ Invalid Parameters
+ Busy
+
+
+Add Extended Advertising Data Command
+=====================================
+
+ Command Code: 0x0055
+ Controller Index: <controller id>
+ Command Parameters: Instance (1 Octet)
+ Advertising Data Length (1 Octet)
+ Scan Response Length (1 Octet)
+ Advertising Data (0-255 Octets)
+ Scan Response (0-255 Octets)
+ Return Parameters: Instance (1 Octet)
+
+ The Add Extended Advertising Data command is used to update the
+ advertising data of an existing advertising instance known to the
+ kernel. It is expected to be called after an Add Extended Advertising
+ Parameters command, as part of the advertisement registration
+ process.
+
+ If extended advertising is available, this call will initiate HCI
+ commands to set the instance's advertising data, set scan response
+ data, and then enable the instance. If extended advertising is
+ unavailable, the advertising instance structure maintained in kernel
+ will have its advertising data and scan response updated, and the
+ instance will either be scheduled immediately or left in the queue
+ for later advertisement as part of round-robin advertisement rotation
+ in software.
+
+ If Scan_Rsp_Len is zero and the flags defined in Add Extended
+ Advertising Parameters command do not have connectable flag set and
+ the global connectable setting is off, then non-connectable
+ advertising is used. If Scan_Rsp_Len is larger than zero and
+ connectable flag is not set and the global advertising is off,
+ then scannable advertising is used. This small difference is
+ supported to provide less air traffic for devices implementing
+ broadcaster role.
+
+ If the Instance provided does not match a known instance, or if the
+ provided advertising data or scan response are in an unrecognized
+ format, an "Invalid Parameters" status will be returned.
+
+ If a "Set LE" or Advertising command is still in progress, a "Busy"
+ status will be returned.
+
+ If the controller is not powered, a "rejected" status will be returned.
+
+ This command generates a Command Complete event on success or a
+ Command Status event on failure.
+
+ Possible errors: Failed
+ Rejected
+ Invalid Parameters
+ Busy
+
+
Command Complete Event
======================
--
2.28.0.709.gb0816b6eb0-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Bluez PATCH v4 03/10] doc/mgmt-api: Update controller capabilities MGMT command in mgmt-api
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
2020-10-01 23:01 ` [Bluez PATCH v4 01/10] doc/advertising-api: update API with new interface Daniel Winkler
2020-10-01 23:01 ` [Bluez PATCH v4 02/10] doc/mgmt-api: Add new Advertising MGMT interfaces to mgmt-api Daniel Winkler
@ 2020-10-01 23:01 ` Daniel Winkler
2020-10-01 23:01 ` [Bluez PATCH v4 04/10] advertising: Detect if extended advertising mgmt commands are supported Daniel Winkler
` (8 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Daniel Winkler @ 2020-10-01 23:01 UTC (permalink / raw)
To: luiz.von.dentz
Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler
This patch changes Read Security Info MGMT to be called Read Controller
Capabilities Command
---
Changes in v4:
- mgmt-api: Move Controller Capabilities MGMT doc into new patch
- mgmt-api: Tx Power range put into single capabilities entry
Changes in v3: None
Changes in v2: None
doc/mgmt-api.txt | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 7c899a8fe..1aa43d6c3 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -3110,19 +3110,19 @@ Set Wideband Speech Command
Invalid Index
-Read Security Information Command
-=================================
+Read Controller Capabilities Command
+====================================
Command Code: 0x0048
Controller Index: <controller id>
Command Parameters:
- Return Parameters: Security_Data_Length (2 Octets)
- Security_Data (0-65535 Octets)
+ Return Parameters: Capabilities_Data_Length (2 Octets)
+ Capabilities_Data (0-65535 Octets)
- This command is used to retrieve the supported security features
+ This command is used to retrieve the supported capabilities
by the controller or the host stack.
- The Security_Data_Length and Security_Data parameters provide
+ The Capabilities_Data_Length and Capabilities_Data parameters provide
a list of security settings, features and information. It uses
the same format as EIR_Data, but with the namespace defined here.
@@ -3131,6 +3131,7 @@ Read Security Information Command
0x01 Flags
0x02 Max Encryption Key Size (BR/EDR)
0x03 Max Encryption Key Size (LE)
+ 0x04 Supported Tx Power (LE)
Flags (data type 0x01)
@@ -3146,6 +3147,14 @@ Read Security Information Command
present, then it is unknown what the max encryption key
size of the controller or host is in use.
+ Supported LE Tx Power (data type 0x04)
+
+ When present, this 2-octet field provides the min and max
+ LE Tx power supported by the controller, respectively, as
+ reported by the LE Read Transmit Power HCI command. If this
+ field is not available, it indicates that the LE Read
+ Transmit Power HCI command was not available.
+
This command generates a Command Complete event on success or
a Command Status event on failure.
--
2.28.0.709.gb0816b6eb0-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Bluez PATCH v4 04/10] advertising: Detect if extended advertising mgmt commands are supported
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
` (2 preceding siblings ...)
2020-10-01 23:01 ` [Bluez PATCH v4 03/10] doc/mgmt-api: Update controller capabilities MGMT command in mgmt-api Daniel Winkler
@ 2020-10-01 23:01 ` Daniel Winkler
2020-10-01 23:01 ` [Bluez PATCH v4 05/10] advertising: Parse intervals and tx power from adv Daniel Winkler
` (7 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Daniel Winkler @ 2020-10-01 23:01 UTC (permalink / raw)
To: luiz.von.dentz
Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler,
Sonny Sasaka, Alain Michaud
We need to know if kernel supports the new MGMT interface. To do so, we
check the return from adapter's MGMT_OP_READ_COMMANDS call for the new
commands. This will later be used to route our requests for new
advertisements.
The change is tested by manually verifying that the correct MGMT
commands are used when the feature is and is not available in kernel.
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
---
Changes in v4: None
Changes in v3: None
Changes in v2:
- Uses btd_has_kernel_features to detect kernel command support
src/adapter.c | 4 ++++
src/adapter.h | 1 +
src/advertising.c | 3 +++
3 files changed, 8 insertions(+)
diff --git a/src/adapter.c b/src/adapter.c
index c0053000a..0e035172e 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -9640,6 +9640,10 @@ static void read_commands_complete(uint8_t status, uint16_t length,
DBG("kernel supports exp features");
kernel_features |= KERNEL_EXP_FEATURES;
break;
+ case MGMT_OP_ADD_EXT_ADV_PARAMS:
+ DBG("kernel supports ext adv commands");
+ kernel_features |= KERNEL_HAS_EXT_ADV_ADD_CMDS;
+ break;
default:
break;
}
diff --git a/src/adapter.h b/src/adapter.h
index dcc574857..ace72affd 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -233,6 +233,7 @@ enum kernel_features {
KERNEL_SET_SYSTEM_CONFIG = 1 << 2,
KERNEL_EXP_FEATURES = 1 << 3,
KERNEL_HAS_RESUME_EVT = 1 << 4,
+ KERNEL_HAS_EXT_ADV_ADD_CMDS = 1 << 5,
};
bool btd_has_kernel_features(uint32_t feature);
diff --git a/src/advertising.c b/src/advertising.c
index c03869e50..7c7599552 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -48,6 +48,7 @@ struct btd_adv_manager {
uint8_t max_ads;
uint32_t supported_flags;
unsigned int instance_bitmap;
+ bool extended_add_cmds;
};
#define AD_TYPE_BROADCAST 0
@@ -1417,6 +1418,8 @@ static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
manager->mgmt_index = btd_adapter_get_index(adapter);
manager->clients = queue_new();
manager->supported_flags = MGMT_ADV_FLAG_LOCAL_NAME;
+ manager->extended_add_cmds =
+ btd_has_kernel_features(KERNEL_HAS_EXT_ADV_ADD_CMDS);
if (!g_dbus_register_interface(btd_get_dbus_connection(),
adapter_get_path(manager->adapter),
--
2.28.0.709.gb0816b6eb0-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Bluez PATCH v4 05/10] advertising: Parse intervals and tx power from adv
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
` (3 preceding siblings ...)
2020-10-01 23:01 ` [Bluez PATCH v4 04/10] advertising: Detect if extended advertising mgmt commands are supported Daniel Winkler
@ 2020-10-01 23:01 ` Daniel Winkler
2020-10-27 22:03 ` Luiz Augusto von Dentz
2020-10-01 23:01 ` [Bluez PATCH v4 06/10] advertising: Use new mgmt interface for advertising add Daniel Winkler
` (6 subsequent siblings)
11 siblings, 1 reply; 18+ messages in thread
From: Daniel Winkler @ 2020-10-01 23:01 UTC (permalink / raw)
To: luiz.von.dentz
Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler,
Sonny Sasaka, Alain Michaud
This change adds parsers for the advertising intervals and tx power
properties of the LEAdvertisement1 object. It validates that each field
adheres to the 5.2 spec, and that min and max intervals are compatible
with each other, i.e. that min interval is less than max interval.
A note here for maintainers: The tx power that is sent in the hci
parameter command is an int8_t, but as far as I can tell, there is no
clean way to use a signed 8-bit integer in dbus. The dbus byte type
seems incompatible with negative values in high-level languages (python)
without awkward usage manipulation on the client side. For this reason,
I chose to use an int16_t type for the tx power dbus field, which is
then downcasted to the int8_t in bluetoothd, which at least makes the
signed-ness of the type crystal clear to the dbus client that uses it.
This change is manually verified by ensuring the intervals and tx power
parameters are correctly parsed from the LEAdvertisement1 object, and
that the parse fails if the parameters are incorrect or not compatible
with each other.
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
src/advertising.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 89 insertions(+)
diff --git a/src/advertising.c b/src/advertising.c
index 7c7599552..3690a2aac 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -54,6 +54,11 @@ struct btd_adv_manager {
#define AD_TYPE_BROADCAST 0
#define AD_TYPE_PERIPHERAL 1
+/* BLUETOOTH SPECIFICATION Version 5.2 | Vol 4, Part E, page 2585
+ * defines tx power value indicating no preference
+ */
+#define ADV_TX_POWER_NO_PREFERENCE 0x7F
+
struct btd_adv_client {
struct btd_adv_manager *manager;
char *owner;
@@ -74,6 +79,9 @@ struct btd_adv_client {
struct bt_ad *data;
struct bt_ad *scan;
uint8_t instance;
+ uint32_t min_interval;
+ uint32_t max_interval;
+ int8_t tx_power;
};
struct dbus_obj_match {
@@ -937,6 +945,74 @@ static bool parse_secondary(DBusMessageIter *iter,
return false;
}
+static bool parse_min_interval(DBusMessageIter *iter,
+ struct btd_adv_client *client)
+{
+ if (!iter)
+ return false;
+
+ if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_UINT32)
+ return false;
+
+ dbus_message_iter_get_basic(iter, &client->min_interval);
+
+ /* BLUETOOTH SPECIFICATION Version 5.2 | Vol 4, Part E, page 2584
+ * defines acceptable interval range
+ */
+ if (client->min_interval < 0x20 || client->min_interval > 0xFFFFFF) {
+ client->min_interval = 0;
+ return false;
+ }
+
+ return true;
+}
+
+static bool parse_max_interval(DBusMessageIter *iter,
+ struct btd_adv_client *client)
+{
+ if (!iter)
+ return false;
+
+ if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_UINT32)
+ return false;
+
+ dbus_message_iter_get_basic(iter, &client->max_interval);
+
+ /* BLUETOOTH SPECIFICATION Version 5.2 | Vol 4, Part E, page 2584
+ * defines acceptable interval range
+ */
+ if (client->max_interval < 0x20 || client->max_interval > 0xFFFFFF) {
+ client->max_interval = 0;
+ return false;
+ }
+
+ return true;
+}
+
+static bool parse_tx_power(DBusMessageIter *iter,
+ struct btd_adv_client *client)
+{
+ int16_t val;
+
+ if (!iter)
+ return false;
+
+ if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_INT16)
+ return false;
+
+ dbus_message_iter_get_basic(iter, &val);
+
+ /* BLUETOOTH SPECIFICATION Version 5.2 | Vol 4, Part E, page 2585
+ * defines acceptable tx power range
+ */
+ if (val < -127 || val > 20)
+ return false;
+
+ client->tx_power = val;
+
+ return true;
+}
+
static struct adv_parser {
const char *name;
bool (*func)(DBusMessageIter *iter, struct btd_adv_client *client);
@@ -955,6 +1031,9 @@ static struct adv_parser {
{ "Discoverable", parse_discoverable },
{ "DiscoverableTimeout", parse_discoverable_timeout },
{ "SecondaryChannel", parse_secondary },
+ { "MinInterval", parse_min_interval },
+ { "MaxInterval", parse_max_interval },
+ { "TxPower", parse_tx_power },
{ },
};
@@ -1083,6 +1162,13 @@ static DBusMessage *parse_advertisement(struct btd_adv_client *client)
goto fail;
}
+ if (client->min_interval > client->max_interval) {
+ /* Min interval must not be bigger than max interval */
+ error("MinInterval must be less than MaxInterval (%lu > %lu)",
+ client->min_interval, client->max_interval);
+ goto fail;
+ }
+
err = refresh_adv(client, add_adv_callback, &client->add_adv_id);
if (!err)
return NULL;
@@ -1158,6 +1244,9 @@ static struct btd_adv_client *client_create(struct btd_adv_manager *manager,
client->manager = manager;
client->appearance = UINT16_MAX;
+ client->tx_power = ADV_TX_POWER_NO_PREFERENCE;
+ client->min_interval = 0;
+ client->max_interval = 0;
return client;
--
2.28.0.709.gb0816b6eb0-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [Bluez PATCH v4 05/10] advertising: Parse intervals and tx power from adv
2020-10-01 23:01 ` [Bluez PATCH v4 05/10] advertising: Parse intervals and tx power from adv Daniel Winkler
@ 2020-10-27 22:03 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 18+ messages in thread
From: Luiz Augusto von Dentz @ 2020-10-27 22:03 UTC (permalink / raw)
To: Daniel Winkler
Cc: Luiz Augusto Von Dentz, linux-bluetooth,
ChromeOS Bluetooth Upstreaming, Sonny Sasaka, Alain Michaud
Hi Daniel,
On Thu, Oct 1, 2020 at 4:05 PM Daniel Winkler <danielwinkler@google.com> wrote:
>
> This change adds parsers for the advertising intervals and tx power
> properties of the LEAdvertisement1 object. It validates that each field
> adheres to the 5.2 spec, and that min and max intervals are compatible
> with each other, i.e. that min interval is less than max interval.
>
> A note here for maintainers: The tx power that is sent in the hci
> parameter command is an int8_t, but as far as I can tell, there is no
> clean way to use a signed 8-bit integer in dbus. The dbus byte type
> seems incompatible with negative values in high-level languages (python)
> without awkward usage manipulation on the client side. For this reason,
> I chose to use an int16_t type for the tx power dbus field, which is
> then downcasted to the int8_t in bluetoothd, which at least makes the
> signed-ness of the type crystal clear to the dbus client that uses it.
>
> This change is manually verified by ensuring the intervals and tx power
> parameters are correctly parsed from the LEAdvertisement1 object, and
> that the parse fails if the parameters are incorrect or not compatible
> with each other.
>
> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
> Reviewed-by: Alain Michaud <alainm@chromium.org>
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> src/advertising.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 89 insertions(+)
>
> diff --git a/src/advertising.c b/src/advertising.c
> index 7c7599552..3690a2aac 100644
> --- a/src/advertising.c
> +++ b/src/advertising.c
> @@ -54,6 +54,11 @@ struct btd_adv_manager {
> #define AD_TYPE_BROADCAST 0
> #define AD_TYPE_PERIPHERAL 1
>
> +/* BLUETOOTH SPECIFICATION Version 5.2 | Vol 4, Part E, page 2585
> + * defines tx power value indicating no preference
> + */
> +#define ADV_TX_POWER_NO_PREFERENCE 0x7F
> +
> struct btd_adv_client {
> struct btd_adv_manager *manager;
> char *owner;
> @@ -74,6 +79,9 @@ struct btd_adv_client {
> struct bt_ad *data;
> struct bt_ad *scan;
> uint8_t instance;
> + uint32_t min_interval;
> + uint32_t max_interval;
> + int8_t tx_power;
> };
>
> struct dbus_obj_match {
> @@ -937,6 +945,74 @@ static bool parse_secondary(DBusMessageIter *iter,
> return false;
> }
>
> +static bool parse_min_interval(DBusMessageIter *iter,
> + struct btd_adv_client *client)
> +{
> + if (!iter)
> + return false;
> +
> + if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_UINT32)
> + return false;
> +
> + dbus_message_iter_get_basic(iter, &client->min_interval);
> +
> + /* BLUETOOTH SPECIFICATION Version 5.2 | Vol 4, Part E, page 2584
> + * defines acceptable interval range
> + */
> + if (client->min_interval < 0x20 || client->min_interval > 0xFFFFFF) {
> + client->min_interval = 0;
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static bool parse_max_interval(DBusMessageIter *iter,
> + struct btd_adv_client *client)
> +{
> + if (!iter)
> + return false;
> +
> + if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_UINT32)
> + return false;
> +
> + dbus_message_iter_get_basic(iter, &client->max_interval);
> +
> + /* BLUETOOTH SPECIFICATION Version 5.2 | Vol 4, Part E, page 2584
> + * defines acceptable interval range
> + */
> + if (client->max_interval < 0x20 || client->max_interval > 0xFFFFFF) {
> + client->max_interval = 0;
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static bool parse_tx_power(DBusMessageIter *iter,
> + struct btd_adv_client *client)
> +{
> + int16_t val;
> +
> + if (!iter)
> + return false;
> +
> + if (dbus_message_iter_get_arg_type(iter) != DBUS_TYPE_INT16)
> + return false;
> +
> + dbus_message_iter_get_basic(iter, &val);
> +
> + /* BLUETOOTH SPECIFICATION Version 5.2 | Vol 4, Part E, page 2585
> + * defines acceptable tx power range
> + */
> + if (val < -127 || val > 20)
> + return false;
> +
> + client->tx_power = val;
> +
> + return true;
> +}
> +
> static struct adv_parser {
> const char *name;
> bool (*func)(DBusMessageIter *iter, struct btd_adv_client *client);
> @@ -955,6 +1031,9 @@ static struct adv_parser {
> { "Discoverable", parse_discoverable },
> { "DiscoverableTimeout", parse_discoverable_timeout },
> { "SecondaryChannel", parse_secondary },
> + { "MinInterval", parse_min_interval },
> + { "MaxInterval", parse_max_interval },
> + { "TxPower", parse_tx_power },
> { },
> };
>
> @@ -1083,6 +1162,13 @@ static DBusMessage *parse_advertisement(struct btd_adv_client *client)
> goto fail;
> }
>
> + if (client->min_interval > client->max_interval) {
> + /* Min interval must not be bigger than max interval */
> + error("MinInterval must be less than MaxInterval (%lu > %lu)",
> + client->min_interval, client->max_interval);
> + goto fail;
> + }
> +
> err = refresh_adv(client, add_adv_callback, &client->add_adv_id);
> if (!err)
> return NULL;
> @@ -1158,6 +1244,9 @@ static struct btd_adv_client *client_create(struct btd_adv_manager *manager,
>
> client->manager = manager;
> client->appearance = UINT16_MAX;
> + client->tx_power = ADV_TX_POWER_NO_PREFERENCE;
> + client->min_interval = 0;
> + client->max_interval = 0;
Lets only parse these if experimental is enabled.
> return client;
>
> --
> 2.28.0.709.gb0816b6eb0-goog
>
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bluez PATCH v4 06/10] advertising: Use new mgmt interface for advertising add
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
` (4 preceding siblings ...)
2020-10-01 23:01 ` [Bluez PATCH v4 05/10] advertising: Parse intervals and tx power from adv Daniel Winkler
@ 2020-10-01 23:01 ` Daniel Winkler
2020-10-01 23:01 ` [Bluez PATCH v4 07/10] advertising: Query LE TX range at manager initialization Daniel Winkler
` (5 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Daniel Winkler @ 2020-10-01 23:01 UTC (permalink / raw)
To: luiz.von.dentz
Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler,
Sonny Sasaka, Alain Michaud
This patch allows bluetoothd to use the new extended advertising add
mgmt interface if it is available. The new interface will be used by
default, as it allows the client to set advertising intervals, and tx
power if the controller and kernel support extended advertising.
Each new registered advertisement will submit two requests to kernel;
the first sets the advertising parameters for the advertising instance,
and the second sets the advertising data and scan response for the
instance.
The parameters MGMT request will return the tx power selected by the
controller (if applicable), which is propagated to the client via a dbus
Set method.
Note: This patch also fixes a small bug in the packet monitor, where the
tx power value 0xff is considered as "Host has no preference". However,
the spec states this value to be 0x7f. It is corrected in this patch
This change has been tested extensively on Hatch (extended advertising)
and Kukui (no extended advertising) chromebooks. Manual tests do the
following:
- Configure advertisement with custom intervals, tx power with valid and
invalid values and combinations
- Ensure that with valid parameters, they are propagated and set in hci
requests. With invalid parameters, ensure that the registration fails.
Automatic tests verify 25 advertising usage scenarios involving single
and multi-advertising registration, over-registration, parameter
validation, etc. These tests don't test new intervals and tx power, but
validate that the new MGMT interface does not regress compatibility in
these 25 scenarios.
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
---
Changes in v4:
- Moved optional params into flags field
- Use returned max data length in adv data length check
Changes in v3:
- Added selected tx power to MGMT params response
Changes in v2:
- Cleaned fail path in add_adv_params_callback
lib/mgmt.h | 32 +++++++
monitor/packet.c | 4 +-
src/advertising.c | 223 ++++++++++++++++++++++++++++++++++++++++++----
3 files changed, 242 insertions(+), 17 deletions(-)
diff --git a/lib/mgmt.h b/lib/mgmt.h
index 6aa0f5f88..7ab4fb797 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -503,6 +503,10 @@ struct mgmt_rp_add_advertising {
#define MGMT_ADV_FLAG_SEC_1M (1 << 7)
#define MGMT_ADV_FLAG_SEC_2M (1 << 8)
#define MGMT_ADV_FLAG_SEC_CODED (1 << 9)
+#define MGMT_ADV_PARAM_DURATION (1 << 12)
+#define MGMT_ADV_PARAM_TIMEOUT (1 << 13)
+#define MGMT_ADV_PARAM_INTERVALS (1 << 14)
+#define MGMT_ADV_PARAM_TX_POWER (1 << 15)
#define MGMT_OP_REMOVE_ADVERTISING 0x003F
struct mgmt_cp_remove_advertising {
@@ -700,6 +704,34 @@ struct mgmt_rp_remove_adv_monitor {
uint16_t monitor_handle;
} __packed;
+#define MGMT_OP_ADD_EXT_ADV_PARAMS 0x0054
+struct mgmt_cp_add_ext_adv_params {
+ uint8_t instance;
+ uint32_t flags;
+ uint16_t duration;
+ uint16_t timeout;
+ uint32_t min_interval;
+ uint32_t max_interval;
+ int8_t tx_power;
+} __packed;
+struct mgmt_rp_add_ext_adv_params {
+ uint8_t instance;
+ int8_t tx_power;
+ uint8_t max_adv_data_len;
+ uint8_t max_scan_rsp_len;
+} __packed;
+
+#define MGMT_OP_ADD_EXT_ADV_DATA 0x0055
+struct mgmt_cp_add_ext_adv_data {
+ uint8_t instance;
+ uint8_t adv_data_len;
+ uint8_t scan_rsp_len;
+ uint8_t data[0];
+} __packed;
+struct mgmt_rp_add_ext_adv_data {
+ uint8_t instance;
+} __packed;
+
#define MGMT_EV_CMD_COMPLETE 0x0001
struct mgmt_ev_cmd_complete {
uint16_t opcode;
diff --git a/monitor/packet.c b/monitor/packet.c
index d83552f74..615c180f8 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -6979,8 +6979,8 @@ static void le_set_ext_adv_params_cmd(const void *data, uint8_t size)
print_peer_addr_type("Peer address type", cmd->peer_addr_type);
print_addr("Peer address", cmd->peer_addr, cmd->peer_addr_type);
print_adv_filter_policy("Filter policy", cmd->filter_policy);
- if (cmd->tx_power == 0xff)
- print_field("TX power: Host has no preference (0xff)");
+ if (cmd->tx_power == 0x7f)
+ print_field("TX power: Host has no preference (0x7f)");
else
print_power_level(cmd->tx_power, NULL);
diff --git a/src/advertising.c b/src/advertising.c
index 3690a2aac..052964d42 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -82,6 +82,7 @@ struct btd_adv_client {
uint32_t min_interval;
uint32_t max_interval;
int8_t tx_power;
+ mgmt_request_func_t refresh_done_func;
};
struct dbus_obj_match {
@@ -788,19 +789,9 @@ static uint8_t *generate_scan_rsp(struct btd_adv_client *client,
return bt_ad_generate(client->scan, len);
}
-static int refresh_adv(struct btd_adv_client *client, mgmt_request_func_t func,
- unsigned int *mgmt_id)
+static int get_adv_flags(struct btd_adv_client *client)
{
- struct mgmt_cp_add_advertising *cp;
- uint8_t param_len;
- uint8_t *adv_data;
- size_t adv_data_len;
- uint8_t *scan_rsp;
- size_t scan_rsp_len = -1;
uint32_t flags = 0;
- unsigned int mgmt_ret;
-
- DBG("Refreshing advertisement: %s", client->path);
if (client->type == AD_TYPE_PERIPHERAL) {
flags = MGMT_ADV_FLAG_CONNECTABLE;
@@ -812,6 +803,26 @@ static int refresh_adv(struct btd_adv_client *client, mgmt_request_func_t func,
flags |= client->flags;
+ return flags;
+}
+
+static int refresh_legacy_adv(struct btd_adv_client *client,
+ mgmt_request_func_t func,
+ unsigned int *mgmt_id)
+{
+ struct mgmt_cp_add_advertising *cp;
+ uint8_t param_len;
+ uint8_t *adv_data;
+ size_t adv_data_len;
+ uint8_t *scan_rsp;
+ size_t scan_rsp_len = -1;
+ uint32_t flags = 0;
+ unsigned int mgmt_ret;
+
+ DBG("Refreshing advertisement: %s", client->path);
+
+ flags = get_adv_flags(client);
+
adv_data = generate_adv_data(client, &flags, &adv_data_len);
if (!adv_data || (adv_data_len > calc_max_adv_len(client, flags))) {
error("Advertising data too long or couldn't be generated.");
@@ -864,6 +875,75 @@ static int refresh_adv(struct btd_adv_client *client, mgmt_request_func_t func,
return 0;
}
+static void add_adv_params_callback(uint8_t status, uint16_t length,
+ const void *param, void *user_data);
+
+static int refresh_extended_adv(struct btd_adv_client *client,
+ mgmt_request_func_t func, unsigned int *mgmt_id)
+{
+ struct mgmt_cp_add_ext_adv_params cp;
+ uint32_t flags = 0;
+ uint16_t included_params = 0;
+ unsigned int mgmt_ret = 0;
+
+ DBG("Refreshing advertisement parameters: %s", client->path);
+
+ flags = get_adv_flags(client);
+
+ memset(&cp, 0, sizeof(cp));
+ cp.instance = client->instance;
+
+ /* Not all advertising instances will use all possible parameters. The
+ * included_params bit field tells the kernel which parameters are
+ * relevant, and sensible defaults will be used for the rest
+ */
+
+ if (client->duration) {
+ cp.duration = client->duration;
+ flags |= MGMT_ADV_PARAM_DURATION;
+ }
+
+ if (client->min_interval && client->max_interval) {
+ cp.min_interval = client->min_interval;
+ cp.max_interval = client->max_interval;
+ flags |= MGMT_ADV_PARAM_INTERVALS;
+ }
+
+ if (client->tx_power != ADV_TX_POWER_NO_PREFERENCE) {
+ cp.tx_power = client->tx_power;
+ flags |= MGMT_ADV_PARAM_TX_POWER;
+ }
+
+ cp.flags = htobl(flags);
+
+ mgmt_ret = mgmt_send(client->manager->mgmt, MGMT_OP_ADD_EXT_ADV_PARAMS,
+ client->manager->mgmt_index, sizeof(cp), &cp,
+ add_adv_params_callback, client, NULL);
+
+ if (!mgmt_ret) {
+ error("Failed to request extended advertising parameters");
+ return -EINVAL;
+ }
+
+ /* Store callback, called after we set advertising data */
+ client->refresh_done_func = func;
+
+ if (mgmt_id)
+ *mgmt_id = mgmt_ret;
+
+
+ return 0;
+}
+
+static int refresh_advertisement(struct btd_adv_client *client,
+ mgmt_request_func_t func, unsigned int *mgmt_id)
+{
+ if (client->manager->extended_add_cmds)
+ return refresh_extended_adv(client, func, mgmt_id);
+
+ return refresh_legacy_adv(client, func, mgmt_id);
+}
+
static gboolean client_discoverable_timeout(void *user_data)
{
struct btd_adv_client *client = user_data;
@@ -874,7 +954,7 @@ static gboolean client_discoverable_timeout(void *user_data)
bt_ad_clear_flags(client->data);
- refresh_adv(client, NULL, NULL);
+ refresh_advertisement(client, NULL, NULL);
return FALSE;
}
@@ -1048,7 +1128,8 @@ static void properties_changed(GDBusProxy *proxy, const char *name,
continue;
if (parser->func(iter, client)) {
- refresh_adv(client, NULL, NULL);
+ refresh_advertisement(client, NULL, NULL);
+
break;
}
}
@@ -1111,6 +1192,112 @@ done:
add_client_complete(client, status);
}
+static void add_adv_params_callback(uint8_t status, uint16_t length,
+ const void *param, void *user_data)
+{
+ struct btd_adv_client *client = user_data;
+ const struct mgmt_rp_add_ext_adv_params *rp = param;
+ struct mgmt_cp_add_ext_adv_data *cp = NULL;
+ uint8_t param_len;
+ uint8_t *adv_data = NULL;
+ size_t adv_data_len;
+ uint8_t *scan_rsp = NULL;
+ size_t scan_rsp_len = -1;
+ uint32_t flags = 0;
+ unsigned int mgmt_ret;
+ dbus_int16_t tx_power;
+
+ if (status)
+ goto fail;
+
+ if (!param || length < sizeof(*rp)) {
+ status = MGMT_STATUS_FAILED;
+ goto fail;
+ }
+
+ DBG("Refreshing advertisement data: %s", client->path);
+
+ /* Update tx power held by client */
+ tx_power = rp->tx_power;
+ if (tx_power != ADV_TX_POWER_NO_PREFERENCE)
+ g_dbus_proxy_set_property_basic(client->proxy, "TxPower",
+ DBUS_TYPE_INT16, &tx_power, NULL, NULL, NULL);
+
+ client->instance = rp->instance;
+
+ flags = get_adv_flags(client);
+
+ adv_data = generate_adv_data(client, &flags, &adv_data_len);
+ if (!adv_data || (adv_data_len > rp->max_adv_data_len)) {
+ error("Advertising data too long or couldn't be generated.");
+ goto fail;
+ }
+
+ scan_rsp = generate_scan_rsp(client, &flags, &scan_rsp_len);
+ if ((!scan_rsp && scan_rsp_len) ||
+ scan_rsp_len > rp->max_scan_rsp_len) {
+ error("Scan data couldn't be generated.");
+ goto fail;
+ }
+
+ param_len = sizeof(struct mgmt_cp_add_advertising) + adv_data_len +
+ scan_rsp_len;
+
+ cp = malloc0(param_len);
+ if (!cp) {
+ error("Couldn't allocate for MGMT!");
+ goto fail;
+ }
+
+ cp->instance = client->instance;
+ cp->adv_data_len = adv_data_len;
+ cp->scan_rsp_len = scan_rsp_len;
+ memcpy(cp->data, adv_data, adv_data_len);
+ memcpy(cp->data + adv_data_len, scan_rsp, scan_rsp_len);
+
+ free(adv_data);
+ free(scan_rsp);
+ adv_data = NULL;
+ scan_rsp = NULL;
+
+ /* Submit request to update instance data */
+ mgmt_ret = mgmt_send(client->manager->mgmt, MGMT_OP_ADD_EXT_ADV_DATA,
+ client->manager->mgmt_index, param_len, cp,
+ client->refresh_done_func, client, NULL);
+
+ /* Clear the callback */
+ client->refresh_done_func = NULL;
+
+ if (!mgmt_ret) {
+ error("Failed to add Advertising Data");
+ goto fail;
+ }
+
+ if (client->add_adv_id)
+ client->add_adv_id = mgmt_ret;
+
+ free(cp);
+ cp = NULL;
+
+ return;
+
+fail:
+ if (adv_data)
+ free(adv_data);
+
+ if (scan_rsp)
+ free(scan_rsp);
+
+ if (cp)
+ free(cp);
+
+ if (!status)
+ status = -EINVAL;
+
+ /* Failure for any reason ends this advertising request */
+ add_client_complete(client, status);
+}
+
static DBusMessage *parse_advertisement(struct btd_adv_client *client)
{
struct adv_parser *parser;
@@ -1169,7 +1356,9 @@ static DBusMessage *parse_advertisement(struct btd_adv_client *client)
goto fail;
}
- err = refresh_adv(client, add_adv_callback, &client->add_adv_id);
+ err = refresh_advertisement(client, add_adv_callback,
+ &client->add_adv_id);
+
if (!err)
return NULL;
@@ -1248,6 +1437,8 @@ static struct btd_adv_client *client_create(struct btd_adv_manager *manager,
client->min_interval = 0;
client->max_interval = 0;
+ client->refresh_done_func = NULL;
+
return client;
fail:
@@ -1564,7 +1755,9 @@ void btd_adv_manager_destroy(struct btd_adv_manager *manager)
static void manager_refresh(void *data, void *user_data)
{
- refresh_adv(data, user_data, NULL);
+ struct btd_adv_client *client = data;
+
+ refresh_advertisement(client, user_data, NULL);
}
void btd_adv_manager_refresh(struct btd_adv_manager *manager)
--
2.28.0.709.gb0816b6eb0-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Bluez PATCH v4 07/10] advertising: Query LE TX range at manager initialization
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
` (5 preceding siblings ...)
2020-10-01 23:01 ` [Bluez PATCH v4 06/10] advertising: Use new mgmt interface for advertising add Daniel Winkler
@ 2020-10-01 23:01 ` Daniel Winkler
2020-10-27 22:08 ` Luiz Augusto von Dentz
2020-10-01 23:01 ` [Bluez PATCH v4 08/10] advertising: Expose SupportedCapabilities for advertising Daniel Winkler
` (4 subsequent siblings)
11 siblings, 1 reply; 18+ messages in thread
From: Daniel Winkler @ 2020-10-01 23:01 UTC (permalink / raw)
To: luiz.von.dentz
Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler,
Sonny Sasaka, Alain Michaud
This patch calls the new MGMT command to get controller capabilities,
and parses the min and max LE tx power range when the manager is
initialized. This will be used to populate a client-facing dbus entry so
that the client will know the advertising capabilities of the controller
before registering an advertisement.
This patch is tested by manually verifying the data is parsed correctly
from the MGMT response.
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
---
Changes in v4:
- Move tx power range into single capability field
Changes in v3: None
Changes in v2: None
lib/mgmt.h | 14 ++++++++----
src/advertising.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++
tools/btmgmt.c | 12 +++++------
3 files changed, 70 insertions(+), 10 deletions(-)
diff --git a/lib/mgmt.h b/lib/mgmt.h
index 7ab4fb797..f37f7e654 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -599,10 +599,16 @@ struct mgmt_cp_set_blocked_keys {
struct mgmt_blocked_key_info keys[0];
} __packed;
-#define MGMT_OP_READ_SECURITY_INFO 0x0048
-struct mgmt_rp_read_security_info {
- uint16_t sec_len;
- uint8_t sec[0];
+#define MGMT_CAP_SEC_FLAGS 0x01
+#define MGMT_CAP_MAX_ENC_KEY_SIZE 0x02
+#define MGMT_CAP_SMP_MAX_ENC_KEY_SIZE 0x03
+#define MGMT_CAP_LE_TX_PWR 0x04
+
+#define MGMT_OP_READ_CONTROLLER_CAP 0x0048
+#define MGMT_READ_CONTROLLER_CAP_SIZE 0
+struct mgmt_rp_read_controller_cap {
+ uint16_t cap_len;
+ uint8_t cap[0];
} __packed;
#define MGMT_OP_READ_EXP_FEATURES_INFO 0x0049
diff --git a/src/advertising.c b/src/advertising.c
index 052964d42..41d0658c8 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -49,6 +49,8 @@ struct btd_adv_manager {
uint32_t supported_flags;
unsigned int instance_bitmap;
bool extended_add_cmds;
+ int8_t min_tx_power;
+ int8_t max_tx_power;
};
#define AD_TYPE_BROADCAST 0
@@ -1679,6 +1681,49 @@ static void read_adv_features_callback(uint8_t status, uint16_t length,
remove_advertising(manager, 0);
}
+static void read_controller_cap_complete(uint8_t status, uint16_t length,
+ const void *param, void *user_data)
+{
+ struct btd_adv_manager *manager = user_data;
+ const struct mgmt_rp_read_controller_cap *rp = param;
+ const uint8_t *ptr = rp->cap;
+ size_t offset = 0;
+ uint8_t tag_len;
+ uint8_t tag_type;
+
+ if (status || !param) {
+ error("Failed to read advertising features: %s (0x%02x)",
+ mgmt_errstr(status), status);
+ return;
+ }
+
+ if (sizeof(rp->cap_len) + rp->cap_len != length) {
+ error("Controller capabilities malformed, size %lu != %u",
+ sizeof(rp->cap_len) + rp->cap_len, length);
+ return;
+ }
+
+ while (offset < rp->cap_len) {
+ tag_len = ptr[offset++];
+ tag_type = ptr[offset++];
+
+ switch (tag_type) {
+ case MGMT_CAP_LE_TX_PWR:
+ if ((tag_len - sizeof(tag_type)) !=
+ 2*sizeof(manager->min_tx_power)) {
+ error("TX power had unexpected length %d",
+ tag_len);
+ break;
+ }
+ memcpy(&manager->min_tx_power, &ptr[offset], tag_len);
+ memcpy(&manager->max_tx_power, &ptr[offset+1], tag_len);
+ }
+
+ /* Step to the next entry */
+ offset += (tag_len - sizeof(tag_type));
+ }
+}
+
static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
struct mgmt *mgmt)
{
@@ -1700,6 +1745,8 @@ static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
manager->supported_flags = MGMT_ADV_FLAG_LOCAL_NAME;
manager->extended_add_cmds =
btd_has_kernel_features(KERNEL_HAS_EXT_ADV_ADD_CMDS);
+ manager->min_tx_power = ADV_TX_POWER_NO_PREFERENCE;
+ manager->max_tx_power = ADV_TX_POWER_NO_PREFERENCE;
if (!g_dbus_register_interface(btd_get_dbus_connection(),
adapter_get_path(manager->adapter),
@@ -1716,6 +1763,13 @@ static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
goto fail;
}
+ /* Query controller capabilities. This will be used to display valid
+ * advertising tx power range to the client.
+ */
+ mgmt_send(manager->mgmt, MGMT_OP_READ_CONTROLLER_CAP,
+ manager->mgmt_index, 0, NULL,
+ read_controller_cap_complete, manager, NULL);
+
return manager;
fail:
diff --git a/tools/btmgmt.c b/tools/btmgmt.c
index 48c9e5887..8b1cc4df5 100644
--- a/tools/btmgmt.c
+++ b/tools/btmgmt.c
@@ -1531,7 +1531,7 @@ static void cmd_extinfo(int argc, char **argv)
static void sec_info_rsp(uint8_t status, uint16_t len, const void *param,
void *user_data)
{
- const struct mgmt_rp_read_security_info *rp = param;
+ const struct mgmt_rp_read_controller_cap *rp = param;
uint16_t index = PTR_TO_UINT(user_data);
if (status != 0) {
@@ -1546,7 +1546,7 @@ static void sec_info_rsp(uint8_t status, uint16_t len, const void *param,
}
print("Primary controller (hci%u)", index);
- print("\tSecurity info length: %u", le16_to_cpu(rp->sec_len));
+ print("\tSecurity info length: %u", le16_to_cpu(rp->cap_len));
done:
pending_index--;
@@ -1589,11 +1589,11 @@ static void sec_index_rsp(uint8_t status, uint16_t len, const void *param,
if (rp->entry[i].type != 0x00)
continue;
- if (!mgmt_send(mgmt, MGMT_OP_READ_SECURITY_INFO,
+ if (!mgmt_send(mgmt, MGMT_OP_READ_CONTROLLER_CAP,
index, 0, NULL, sec_info_rsp,
UINT_TO_PTR(index), NULL)) {
- error("Unable to send read_security_info cmd");
- return bt_shell_noninteractive_quit(EXIT_FAILURE);
+ error("Unable to send read_security_info cmd");
+ return bt_shell_noninteractive_quit(EXIT_FAILURE);
}
pending_index++;
}
@@ -1615,7 +1615,7 @@ static void cmd_secinfo(int argc, char **argv)
return;
}
- if (!mgmt_send(mgmt, MGMT_OP_READ_SECURITY_INFO, mgmt_index, 0, NULL,
+ if (!mgmt_send(mgmt, MGMT_OP_READ_CONTROLLER_CAP, mgmt_index, 0, NULL,
sec_info_rsp,
UINT_TO_PTR(mgmt_index), NULL)) {
error("Unable to send read_security_info cmd");
--
2.28.0.709.gb0816b6eb0-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [Bluez PATCH v4 07/10] advertising: Query LE TX range at manager initialization
2020-10-01 23:01 ` [Bluez PATCH v4 07/10] advertising: Query LE TX range at manager initialization Daniel Winkler
@ 2020-10-27 22:08 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 18+ messages in thread
From: Luiz Augusto von Dentz @ 2020-10-27 22:08 UTC (permalink / raw)
To: Daniel Winkler
Cc: Luiz Augusto Von Dentz, linux-bluetooth,
ChromeOS Bluetooth Upstreaming, Sonny Sasaka, Alain Michaud
Hi Daniel,
On Thu, Oct 1, 2020 at 4:05 PM Daniel Winkler <danielwinkler@google.com> wrote:
>
> This patch calls the new MGMT command to get controller capabilities,
> and parses the min and max LE tx power range when the manager is
> initialized. This will be used to populate a client-facing dbus entry so
> that the client will know the advertising capabilities of the controller
> before registering an advertisement.
>
> This patch is tested by manually verifying the data is parsed correctly
> from the MGMT response.
>
> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
> Reviewed-by: Alain Michaud <alainm@chromium.org>
> ---
>
> Changes in v4:
> - Move tx power range into single capability field
>
> Changes in v3: None
> Changes in v2: None
>
> lib/mgmt.h | 14 ++++++++----
> src/advertising.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++
> tools/btmgmt.c | 12 +++++------
> 3 files changed, 70 insertions(+), 10 deletions(-)
>
> diff --git a/lib/mgmt.h b/lib/mgmt.h
> index 7ab4fb797..f37f7e654 100644
> --- a/lib/mgmt.h
> +++ b/lib/mgmt.h
> @@ -599,10 +599,16 @@ struct mgmt_cp_set_blocked_keys {
> struct mgmt_blocked_key_info keys[0];
> } __packed;
>
> -#define MGMT_OP_READ_SECURITY_INFO 0x0048
> -struct mgmt_rp_read_security_info {
> - uint16_t sec_len;
> - uint8_t sec[0];
> +#define MGMT_CAP_SEC_FLAGS 0x01
> +#define MGMT_CAP_MAX_ENC_KEY_SIZE 0x02
> +#define MGMT_CAP_SMP_MAX_ENC_KEY_SIZE 0x03
> +#define MGMT_CAP_LE_TX_PWR 0x04
> +
> +#define MGMT_OP_READ_CONTROLLER_CAP 0x0048
> +#define MGMT_READ_CONTROLLER_CAP_SIZE 0
> +struct mgmt_rp_read_controller_cap {
> + uint16_t cap_len;
> + uint8_t cap[0];
> } __packed;
>
> #define MGMT_OP_READ_EXP_FEATURES_INFO 0x0049
> diff --git a/src/advertising.c b/src/advertising.c
> index 052964d42..41d0658c8 100644
> --- a/src/advertising.c
> +++ b/src/advertising.c
> @@ -49,6 +49,8 @@ struct btd_adv_manager {
> uint32_t supported_flags;
> unsigned int instance_bitmap;
> bool extended_add_cmds;
> + int8_t min_tx_power;
> + int8_t max_tx_power;
> };
>
> #define AD_TYPE_BROADCAST 0
> @@ -1679,6 +1681,49 @@ static void read_adv_features_callback(uint8_t status, uint16_t length,
> remove_advertising(manager, 0);
> }
>
> +static void read_controller_cap_complete(uint8_t status, uint16_t length,
> + const void *param, void *user_data)
> +{
> + struct btd_adv_manager *manager = user_data;
> + const struct mgmt_rp_read_controller_cap *rp = param;
> + const uint8_t *ptr = rp->cap;
> + size_t offset = 0;
> + uint8_t tag_len;
> + uint8_t tag_type;
> +
> + if (status || !param) {
> + error("Failed to read advertising features: %s (0x%02x)",
> + mgmt_errstr(status), status);
> + return;
> + }
> +
> + if (sizeof(rp->cap_len) + rp->cap_len != length) {
> + error("Controller capabilities malformed, size %lu != %u",
> + sizeof(rp->cap_len) + rp->cap_len, length);
> + return;
> + }
> +
> + while (offset < rp->cap_len) {
> + tag_len = ptr[offset++];
> + tag_type = ptr[offset++];
> +
> + switch (tag_type) {
> + case MGMT_CAP_LE_TX_PWR:
> + if ((tag_len - sizeof(tag_type)) !=
> + 2*sizeof(manager->min_tx_power)) {
> + error("TX power had unexpected length %d",
> + tag_len);
> + break;
> + }
> + memcpy(&manager->min_tx_power, &ptr[offset], tag_len);
> + memcpy(&manager->max_tx_power, &ptr[offset+1], tag_len);
> + }
> +
> + /* Step to the next entry */
> + offset += (tag_len - sizeof(tag_type));
> + }
> +}
> +
> static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
> struct mgmt *mgmt)
> {
> @@ -1700,6 +1745,8 @@ static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
> manager->supported_flags = MGMT_ADV_FLAG_LOCAL_NAME;
> manager->extended_add_cmds =
> btd_has_kernel_features(KERNEL_HAS_EXT_ADV_ADD_CMDS);
> + manager->min_tx_power = ADV_TX_POWER_NO_PREFERENCE;
> + manager->max_tx_power = ADV_TX_POWER_NO_PREFERENCE;
>
> if (!g_dbus_register_interface(btd_get_dbus_connection(),
> adapter_get_path(manager->adapter),
> @@ -1716,6 +1763,13 @@ static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
> goto fail;
> }
>
> + /* Query controller capabilities. This will be used to display valid
> + * advertising tx power range to the client.
> + */
> + mgmt_send(manager->mgmt, MGMT_OP_READ_CONTROLLER_CAP,
> + manager->mgmt_index, 0, NULL,
> + read_controller_cap_complete, manager, NULL);
I'd make this conditional to experimental for now, also don't we need
to check the kernel has support for it?
> return manager;
>
> fail:
> diff --git a/tools/btmgmt.c b/tools/btmgmt.c
> index 48c9e5887..8b1cc4df5 100644
> --- a/tools/btmgmt.c
> +++ b/tools/btmgmt.c
> @@ -1531,7 +1531,7 @@ static void cmd_extinfo(int argc, char **argv)
> static void sec_info_rsp(uint8_t status, uint16_t len, const void *param,
> void *user_data)
> {
> - const struct mgmt_rp_read_security_info *rp = param;
> + const struct mgmt_rp_read_controller_cap *rp = param;
> uint16_t index = PTR_TO_UINT(user_data);
>
> if (status != 0) {
> @@ -1546,7 +1546,7 @@ static void sec_info_rsp(uint8_t status, uint16_t len, const void *param,
> }
>
> print("Primary controller (hci%u)", index);
> - print("\tSecurity info length: %u", le16_to_cpu(rp->sec_len));
> + print("\tSecurity info length: %u", le16_to_cpu(rp->cap_len));
>
> done:
> pending_index--;
> @@ -1589,11 +1589,11 @@ static void sec_index_rsp(uint8_t status, uint16_t len, const void *param,
> if (rp->entry[i].type != 0x00)
> continue;
>
> - if (!mgmt_send(mgmt, MGMT_OP_READ_SECURITY_INFO,
> + if (!mgmt_send(mgmt, MGMT_OP_READ_CONTROLLER_CAP,
> index, 0, NULL, sec_info_rsp,
> UINT_TO_PTR(index), NULL)) {
> - error("Unable to send read_security_info cmd");
> - return bt_shell_noninteractive_quit(EXIT_FAILURE);
> + error("Unable to send read_security_info cmd");
> + return bt_shell_noninteractive_quit(EXIT_FAILURE);
> }
> pending_index++;
> }
> @@ -1615,7 +1615,7 @@ static void cmd_secinfo(int argc, char **argv)
> return;
> }
>
> - if (!mgmt_send(mgmt, MGMT_OP_READ_SECURITY_INFO, mgmt_index, 0, NULL,
> + if (!mgmt_send(mgmt, MGMT_OP_READ_CONTROLLER_CAP, mgmt_index, 0, NULL,
> sec_info_rsp,
> UINT_TO_PTR(mgmt_index), NULL)) {
> error("Unable to send read_security_info cmd");
> --
> 2.28.0.709.gb0816b6eb0-goog
>
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bluez PATCH v4 08/10] advertising: Expose SupportedCapabilities for advertising
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
` (6 preceding siblings ...)
2020-10-01 23:01 ` [Bluez PATCH v4 07/10] advertising: Query LE TX range at manager initialization Daniel Winkler
@ 2020-10-01 23:01 ` Daniel Winkler
2020-10-27 22:05 ` Luiz Augusto von Dentz
2020-10-01 23:01 ` [Bluez PATCH v4 09/10] client: Add SupportedCapabilities to bluetoothctl Daniel Winkler
` (3 subsequent siblings)
11 siblings, 1 reply; 18+ messages in thread
From: Daniel Winkler @ 2020-10-01 23:01 UTC (permalink / raw)
To: luiz.von.dentz
Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler,
Sonny Sasaka, Alain Michaud
To help our advertising clients understand the device capabilities, this
patch adds a SupportedCapabilities dbus endpoint for the advertising
manager. The primary reason behind this is to provide the valid LE tx
power range the controller supports (populated if controller supports
BT5), so a client can know the valid power range before requesting a tx
power for their advertisement.
I also thought it would be useful to indicate the max advertising data
length and scan response length in this endpoint, since some clients
will find it useful to set their advertising data (currently
experimental feature) or scan response data (possible future feature)
directly.
This patch has been tested on Hatch (BT5 support) and Kukui (No BT5
support) chromebooks to verify that the dbus endpoint contains the
correct data.
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
src/advertising.c | 34 ++++++++++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/src/advertising.c b/src/advertising.c
index 41d0658c8..f76831594 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -1619,12 +1619,46 @@ static gboolean get_supported_secondary(const GDBusPropertyTable *property,
return TRUE;
}
+static gboolean get_supported_cap(const GDBusPropertyTable *property,
+ DBusMessageIter *iter, void *data)
+{
+ struct btd_adv_manager *manager = data;
+ DBusMessageIter dict;
+ int16_t min_tx_power = manager->min_tx_power;
+ int16_t max_tx_power = manager->max_tx_power;
+
+ dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY,
+ DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING
+ DBUS_TYPE_STRING_AS_STRING
+ DBUS_TYPE_VARIANT_AS_STRING
+ DBUS_DICT_ENTRY_END_CHAR_AS_STRING,
+ &dict);
+
+ if (min_tx_power != ADV_TX_POWER_NO_PREFERENCE)
+ dict_append_entry(&dict, "MinTxPower", DBUS_TYPE_INT16,
+ &min_tx_power);
+
+ if (max_tx_power != ADV_TX_POWER_NO_PREFERENCE)
+ dict_append_entry(&dict, "MaxTxPower", DBUS_TYPE_INT16,
+ &max_tx_power);
+
+ dict_append_entry(&dict, "MaxAdvLen", DBUS_TYPE_BYTE,
+ &manager->max_adv_len);
+ dict_append_entry(&dict, "MaxScnRspLen", DBUS_TYPE_BYTE,
+ &manager->max_scan_rsp_len);
+
+ dbus_message_iter_close_container(iter, &dict);
+
+ return TRUE;
+}
+
static const GDBusPropertyTable properties[] = {
{ "ActiveInstances", "y", get_active_instances, NULL, NULL },
{ "SupportedInstances", "y", get_instances, NULL, NULL },
{ "SupportedIncludes", "as", get_supported_includes, NULL, NULL },
{ "SupportedSecondaryChannels", "as", get_supported_secondary, NULL,
secondary_exits },
+ { "SupportedCapabilities", "a{sv}", get_supported_cap, NULL, NULL},
{ }
};
--
2.28.0.709.gb0816b6eb0-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [Bluez PATCH v4 08/10] advertising: Expose SupportedCapabilities for advertising
2020-10-01 23:01 ` [Bluez PATCH v4 08/10] advertising: Expose SupportedCapabilities for advertising Daniel Winkler
@ 2020-10-27 22:05 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 18+ messages in thread
From: Luiz Augusto von Dentz @ 2020-10-27 22:05 UTC (permalink / raw)
To: Daniel Winkler
Cc: Luiz Augusto Von Dentz, linux-bluetooth,
ChromeOS Bluetooth Upstreaming, Sonny Sasaka, Alain Michaud
Hi Daniel,
On Thu, Oct 1, 2020 at 4:07 PM Daniel Winkler <danielwinkler@google.com> wrote:
>
> To help our advertising clients understand the device capabilities, this
> patch adds a SupportedCapabilities dbus endpoint for the advertising
> manager. The primary reason behind this is to provide the valid LE tx
> power range the controller supports (populated if controller supports
> BT5), so a client can know the valid power range before requesting a tx
> power for their advertisement.
>
> I also thought it would be useful to indicate the max advertising data
> length and scan response length in this endpoint, since some clients
> will find it useful to set their advertising data (currently
> experimental feature) or scan response data (possible future feature)
> directly.
>
> This patch has been tested on Hatch (BT5 support) and Kukui (No BT5
> support) chromebooks to verify that the dbus endpoint contains the
> correct data.
>
> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
> Reviewed-by: Alain Michaud <alainm@chromium.org>
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
>
> src/advertising.c | 34 ++++++++++++++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/src/advertising.c b/src/advertising.c
> index 41d0658c8..f76831594 100644
> --- a/src/advertising.c
> +++ b/src/advertising.c
> @@ -1619,12 +1619,46 @@ static gboolean get_supported_secondary(const GDBusPropertyTable *property,
> return TRUE;
> }
>
> +static gboolean get_supported_cap(const GDBusPropertyTable *property,
> + DBusMessageIter *iter, void *data)
> +{
> + struct btd_adv_manager *manager = data;
> + DBusMessageIter dict;
> + int16_t min_tx_power = manager->min_tx_power;
> + int16_t max_tx_power = manager->max_tx_power;
> +
> + dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY,
> + DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING
> + DBUS_TYPE_STRING_AS_STRING
> + DBUS_TYPE_VARIANT_AS_STRING
> + DBUS_DICT_ENTRY_END_CHAR_AS_STRING,
> + &dict);
> +
> + if (min_tx_power != ADV_TX_POWER_NO_PREFERENCE)
> + dict_append_entry(&dict, "MinTxPower", DBUS_TYPE_INT16,
> + &min_tx_power);
> +
> + if (max_tx_power != ADV_TX_POWER_NO_PREFERENCE)
> + dict_append_entry(&dict, "MaxTxPower", DBUS_TYPE_INT16,
> + &max_tx_power);
> +
> + dict_append_entry(&dict, "MaxAdvLen", DBUS_TYPE_BYTE,
> + &manager->max_adv_len);
> + dict_append_entry(&dict, "MaxScnRspLen", DBUS_TYPE_BYTE,
> + &manager->max_scan_rsp_len);
> +
> + dbus_message_iter_close_container(iter, &dict);
> +
> + return TRUE;
> +}
> +
> static const GDBusPropertyTable properties[] = {
> { "ActiveInstances", "y", get_active_instances, NULL, NULL },
> { "SupportedInstances", "y", get_instances, NULL, NULL },
> { "SupportedIncludes", "as", get_supported_includes, NULL, NULL },
> { "SupportedSecondaryChannels", "as", get_supported_secondary, NULL,
> secondary_exits },
> + { "SupportedCapabilities", "a{sv}", get_supported_cap, NULL, NULL},
Lets mark this as experimental for now.
> { }
> };
>
> --
> 2.28.0.709.gb0816b6eb0-goog
>
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bluez PATCH v4 09/10] client: Add SupportedCapabilities to bluetoothctl
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
` (7 preceding siblings ...)
2020-10-01 23:01 ` [Bluez PATCH v4 08/10] advertising: Expose SupportedCapabilities for advertising Daniel Winkler
@ 2020-10-01 23:01 ` Daniel Winkler
2020-10-01 23:01 ` [Bluez PATCH v4 10/10] monitor: Add new MGMT adv commands and events to monitor Daniel Winkler
` (2 subsequent siblings)
11 siblings, 0 replies; 18+ messages in thread
From: Daniel Winkler @ 2020-10-01 23:01 UTC (permalink / raw)
To: luiz.von.dentz
Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler,
Sonny Sasaka, Alain Michaud
This patch adds the new "SupportedCapabilities" property to the
bluetoothctl "show" view.
The change is tested by verifying bluetoothctl shows the desired
properties.
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
---
Changes in v4: None
Changes in v3: None
Changes in v2: None
client/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/client/main.c b/client/main.c
index 60f1eb86e..9403f1af6 100644
--- a/client/main.c
+++ b/client/main.c
@@ -941,6 +941,7 @@ static void cmd_show(int argc, char *argv[])
print_property(adapter->ad_proxy, "SupportedInstances");
print_property(adapter->ad_proxy, "SupportedIncludes");
print_property(adapter->ad_proxy, "SupportedSecondaryChannels");
+ print_property(adapter->ad_proxy, "SupportedCapabilities");
}
if (adapter->adv_monitor_proxy) {
--
2.28.0.709.gb0816b6eb0-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread* [Bluez PATCH v4 10/10] monitor: Add new MGMT adv commands and events to monitor
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
` (8 preceding siblings ...)
2020-10-01 23:01 ` [Bluez PATCH v4 09/10] client: Add SupportedCapabilities to bluetoothctl Daniel Winkler
@ 2020-10-01 23:01 ` Daniel Winkler
2020-10-12 15:53 ` [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
2020-10-26 22:02 ` Daniel Winkler
11 siblings, 0 replies; 18+ messages in thread
From: Daniel Winkler @ 2020-10-01 23:01 UTC (permalink / raw)
To: luiz.von.dentz
Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler,
Sonny Sasaka, Alain Michaud
This change adds the following to packet monitor:
-Add Ext Adv Params command and response
-Add Ext Adv Data command and response
This patch was manually tested by registering advertisements with
various features and verifying in btmon log.
Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
---
Changes in v4: None
Changes in v3:
- Removed Tx Power Selected MGMT event from monitor
Changes in v2: None
monitor/packet.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/monitor/packet.c b/monitor/packet.c
index 615c180f8..b67510f6d 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -11844,8 +11844,16 @@ static const struct bitfield_data mgmt_adv_flags_table[] = {
{ 7, "Advertise in 1M on Secondary channel" },
{ 8, "Advertise in 2M on Secondary channel" },
{ 9, "Advertise in CODED on Secondary channel" },
+ { 12, "Use provided duration parameter" },
+ { 13, "Use provided timeout parameter" },
+ { 14, "Use provided interval parameters" },
+ { 15, "Use provided tx power parameter" },
{ }
};
+#define MGMT_ADV_PARAM_DURATION (1 << 12)
+#define MGMT_ADV_PARAM_TIMEOUT (1 << 13)
+#define MGMT_ADV_PARAM_INTERVALS (1 << 14)
+#define MGMT_ADV_PARAM_TX_POWER (1 << 15)
static void mgmt_print_adv_flags(uint32_t flags)
{
@@ -13150,6 +13158,57 @@ static void mgmt_set_device_flags_rsp(const void *data, uint16_t size)
mgmt_print_address(data, type);
}
+static void mgmt_add_ext_adv_params_cmd(const void *data, uint16_t size)
+{
+ uint8_t instance = get_u8(data);
+ uint32_t flags = get_le32(data + 1);
+ uint16_t duration = get_le16(data + 5);
+ uint16_t timeout = get_le16(data + 7);
+ uint8_t *min_interval = (uint8_t *)(data + 9);
+ uint8_t *max_interval = (uint8_t *)(data + 13);
+ int8_t tx_power = get_s8(data + 17);
+
+ print_field("Instance: %u", instance);
+ mgmt_print_adv_flags(flags);
+ print_field("Duration: %u", duration);
+ print_field("Timeout: %u", timeout);
+ print_ext_slot_625("Min advertising interval", min_interval);
+ print_ext_slot_625("Max advertising interval", max_interval);
+ print_power_level(tx_power, NULL);
+}
+
+static void mgmt_add_ext_adv_params_rsp(const void *data, uint16_t size)
+{
+ uint8_t instance = get_u8(data);
+ int8_t tx_power = get_s8(data + 1);
+ uint8_t max_adv_data_len = get_u8(data+2);
+ uint8_t max_scan_rsp_len = get_u8(data+3);
+
+ print_field("Instance: %u", instance);
+ print_power_level(tx_power, NULL);
+ print_field("Available adv data len: %u", max_adv_data_len);
+ print_field("Available scan rsp data len: %u", max_scan_rsp_len);
+}
+
+static void mgmt_add_ext_adv_data_cmd(const void *data, uint16_t size)
+{
+ uint8_t instance = get_u8(data);
+ uint8_t adv_data_len = get_u8(data + 1);
+ uint8_t scan_rsp_len = get_u8(data + 2);
+
+ print_field("Instance: %u", instance);
+ print_field("Advertising data length: %u", adv_data_len);
+ print_eir(data + 3, adv_data_len, false);
+ print_field("Scan response length: %u", scan_rsp_len);
+ print_eir(data + 3 + adv_data_len, scan_rsp_len, false);
+}
+
+static void mgmt_add_ext_adv_data_rsp(const void *data, uint16_t size)
+{
+ uint8_t instance = get_u8(data);
+
+ print_field("Instance: %u", instance);
+}
struct mgmt_data {
uint16_t opcode;
@@ -13382,6 +13441,12 @@ static const struct mgmt_data mgmt_command_table[] = {
{ 0x0050, "Set Device Flags",
mgmt_set_device_flags_cmd, 11, true,
mgmt_set_device_flags_rsp, 7, true},
+ { 0x0054, "Add Ext Adv Params",
+ mgmt_add_ext_adv_params_cmd, 18, false,
+ mgmt_add_ext_adv_params_rsp, 4, true },
+ { 0x0055, "Add Ext Adv Data",
+ mgmt_add_ext_adv_data_cmd, 3, false,
+ mgmt_add_ext_adv_data_rsp, 1, true },
{ }
};
--
2.28.0.709.gb0816b6eb0-goog
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
` (9 preceding siblings ...)
2020-10-01 23:01 ` [Bluez PATCH v4 10/10] monitor: Add new MGMT adv commands and events to monitor Daniel Winkler
@ 2020-10-12 15:53 ` Daniel Winkler
2020-10-26 22:02 ` Daniel Winkler
11 siblings, 0 replies; 18+ messages in thread
From: Daniel Winkler @ 2020-10-12 15:53 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: BlueZ, chromeos-bluetooth-upstreaming
Hi Maintainers,
Just a friendly ping to take a look at this series at your
convenience. The latest series should address the issues from the
previous ones. Thanks in advance!
Best,
Daniel
On Thu, Oct 1, 2020 at 4:01 PM Daniel Winkler <danielwinkler@google.com> wrote:
>
> Hi Maintainers,
>
> This patch series defines the new two-call MGMT interface in userspace
> for adding advertising instances. Bluez will detect if kernel supports
> the new MGMT commands, and use them if so. Each new advertising instance
> will be configured by a MGMT call to set advertising parameters,
> followed by a MGMT call to set advertising data. The new data pipeline
> is meant to be unnoticeable from the clients' perspective, with the
> exception of new intervals and tx power support, and new exposed
> advertising manager properties.
>
> All changes have been tested on hatch (extended advertising) and kukui
> (no extended advertising) chromebooks with manual testing verifying
> correctness of parameters/data in btmon traces, and our automated test
> suite of 25 single- and multi-advertising usage scenarios.
>
> V2 of the series puts documentation at the front as requested.
>
> Thank you in advance for your review!
> Daniel Winkler
>
>
> Changes in v4:
> - mgmt-api: moved optional params into 'flags' field
> - mgmt-api: added info for new return parameters for max data size
> - mgmt-api: Move Controller Capabilities MGMT doc into new patch
> - mgmt-api: Tx Power range put into single capabilities entry
> - Moved optional params into flags field
> - Use returned max data length in adv data length check
> - Move tx power range into single capability field
>
> Changes in v3:
> - Removed Tx Power Selected MGMT event
> - Changed Read Security Info cmd to Read Controller Capabilities
> - Added selected tx power to MGMT params response
> - Removed Tx Power Selected MGMT event from monitor
>
> Changes in v2:
> - Removed extra space in Add Extended Advertising Parameters API
> - Uses btd_has_kernel_features to detect kernel command support
> - Cleaned fail path in add_adv_params_callback
>
> Daniel Winkler (10):
> doc/advertising-api: update API with new interface
> doc/mgmt-api: Add new Advertising MGMT interfaces to mgmt-api
> doc/mgmt-api: Update controller capabilities MGMT command in mgmt-api
> advertising: Detect if extended advertising mgmt commands are
> supported
> advertising: Parse intervals and tx power from adv
> advertising: Use new mgmt interface for advertising add
> advertising: Query LE TX range at manager initialization
> advertising: Expose SupportedCapabilities for advertising
> client: Add SupportedCapabilities to bluetoothctl
> monitor: Add new MGMT adv commands and events to monitor
>
> client/main.c | 1 +
> doc/advertising-api.txt | 50 +++++
> doc/mgmt-api.txt | 238 +++++++++++++++++++++++-
> lib/mgmt.h | 46 ++++-
> monitor/packet.c | 69 ++++++-
> src/adapter.c | 4 +
> src/adapter.h | 1 +
> src/advertising.c | 403 ++++++++++++++++++++++++++++++++++++++--
> tools/btmgmt.c | 12 +-
> 9 files changed, 791 insertions(+), 33 deletions(-)
>
> --
> 2.28.0.709.gb0816b6eb0-goog
>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add
2020-10-01 23:01 [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
` (10 preceding siblings ...)
2020-10-12 15:53 ` [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
@ 2020-10-26 22:02 ` Daniel Winkler
2020-10-27 22:13 ` Luiz Augusto von Dentz
11 siblings, 1 reply; 18+ messages in thread
From: Daniel Winkler @ 2020-10-26 22:02 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: BlueZ, chromeos-bluetooth-upstreaming
Hello Maintainers,
Pinging again to see if there is further feedback on this advertising
patch series. Please let me know if there are any further comments
that I can address.
Best regards,
Daniel
On Thu, Oct 1, 2020 at 4:01 PM Daniel Winkler <danielwinkler@google.com> wrote:
>
> Hi Maintainers,
>
> This patch series defines the new two-call MGMT interface in userspace
> for adding advertising instances. Bluez will detect if kernel supports
> the new MGMT commands, and use them if so. Each new advertising instance
> will be configured by a MGMT call to set advertising parameters,
> followed by a MGMT call to set advertising data. The new data pipeline
> is meant to be unnoticeable from the clients' perspective, with the
> exception of new intervals and tx power support, and new exposed
> advertising manager properties.
>
> All changes have been tested on hatch (extended advertising) and kukui
> (no extended advertising) chromebooks with manual testing verifying
> correctness of parameters/data in btmon traces, and our automated test
> suite of 25 single- and multi-advertising usage scenarios.
>
> V2 of the series puts documentation at the front as requested.
>
> Thank you in advance for your review!
> Daniel Winkler
>
>
> Changes in v4:
> - mgmt-api: moved optional params into 'flags' field
> - mgmt-api: added info for new return parameters for max data size
> - mgmt-api: Move Controller Capabilities MGMT doc into new patch
> - mgmt-api: Tx Power range put into single capabilities entry
> - Moved optional params into flags field
> - Use returned max data length in adv data length check
> - Move tx power range into single capability field
>
> Changes in v3:
> - Removed Tx Power Selected MGMT event
> - Changed Read Security Info cmd to Read Controller Capabilities
> - Added selected tx power to MGMT params response
> - Removed Tx Power Selected MGMT event from monitor
>
> Changes in v2:
> - Removed extra space in Add Extended Advertising Parameters API
> - Uses btd_has_kernel_features to detect kernel command support
> - Cleaned fail path in add_adv_params_callback
>
> Daniel Winkler (10):
> doc/advertising-api: update API with new interface
> doc/mgmt-api: Add new Advertising MGMT interfaces to mgmt-api
> doc/mgmt-api: Update controller capabilities MGMT command in mgmt-api
> advertising: Detect if extended advertising mgmt commands are
> supported
> advertising: Parse intervals and tx power from adv
> advertising: Use new mgmt interface for advertising add
> advertising: Query LE TX range at manager initialization
> advertising: Expose SupportedCapabilities for advertising
> client: Add SupportedCapabilities to bluetoothctl
> monitor: Add new MGMT adv commands and events to monitor
>
> client/main.c | 1 +
> doc/advertising-api.txt | 50 +++++
> doc/mgmt-api.txt | 238 +++++++++++++++++++++++-
> lib/mgmt.h | 46 ++++-
> monitor/packet.c | 69 ++++++-
> src/adapter.c | 4 +
> src/adapter.h | 1 +
> src/advertising.c | 403 ++++++++++++++++++++++++++++++++++++++--
> tools/btmgmt.c | 12 +-
> 9 files changed, 791 insertions(+), 33 deletions(-)
>
> --
> 2.28.0.709.gb0816b6eb0-goog
>
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Bluez PATCH v4 00/10] Bluetooth: Add new MGMT interface for advertising add
2020-10-26 22:02 ` Daniel Winkler
@ 2020-10-27 22:13 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 18+ messages in thread
From: Luiz Augusto von Dentz @ 2020-10-27 22:13 UTC (permalink / raw)
To: Daniel Winkler
Cc: Luiz Augusto von Dentz, BlueZ, chromeos-bluetooth-upstreaming
Hi Daniel, Marcel,
On Mon, Oct 26, 2020 at 5:09 PM Daniel Winkler <danielwinkler@google.com> wrote:
>
> Hello Maintainers,
>
> Pinging again to see if there is further feedback on this advertising
> patch series. Please let me know if there are any further comments
> that I can address.
>
> Best regards,
> Daniel
>
>
> On Thu, Oct 1, 2020 at 4:01 PM Daniel Winkler <danielwinkler@google.com> wrote:
> >
> > Hi Maintainers,
> >
> > This patch series defines the new two-call MGMT interface in userspace
> > for adding advertising instances. Bluez will detect if kernel supports
> > the new MGMT commands, and use them if so. Each new advertising instance
> > will be configured by a MGMT call to set advertising parameters,
> > followed by a MGMT call to set advertising data. The new data pipeline
> > is meant to be unnoticeable from the clients' perspective, with the
> > exception of new intervals and tx power support, and new exposed
> > advertising manager properties.
> >
> > All changes have been tested on hatch (extended advertising) and kukui
> > (no extended advertising) chromebooks with manual testing verifying
> > correctness of parameters/data in btmon traces, and our automated test
> > suite of 25 single- and multi-advertising usage scenarios.
> >
> > V2 of the series puts documentation at the front as requested.
> >
> > Thank you in advance for your review!
> > Daniel Winkler
> >
> >
> > Changes in v4:
> > - mgmt-api: moved optional params into 'flags' field
> > - mgmt-api: added info for new return parameters for max data size
> > - mgmt-api: Move Controller Capabilities MGMT doc into new patch
> > - mgmt-api: Tx Power range put into single capabilities entry
> > - Moved optional params into flags field
> > - Use returned max data length in adv data length check
> > - Move tx power range into single capability field
> >
> > Changes in v3:
> > - Removed Tx Power Selected MGMT event
> > - Changed Read Security Info cmd to Read Controller Capabilities
> > - Added selected tx power to MGMT params response
> > - Removed Tx Power Selected MGMT event from monitor
> >
> > Changes in v2:
> > - Removed extra space in Add Extended Advertising Parameters API
> > - Uses btd_has_kernel_features to detect kernel command support
> > - Cleaned fail path in add_adv_params_callback
> >
> > Daniel Winkler (10):
> > doc/advertising-api: update API with new interface
> > doc/mgmt-api: Add new Advertising MGMT interfaces to mgmt-api
> > doc/mgmt-api: Update controller capabilities MGMT command in mgmt-api
> > advertising: Detect if extended advertising mgmt commands are
> > supported
> > advertising: Parse intervals and tx power from adv
> > advertising: Use new mgmt interface for advertising add
> > advertising: Query LE TX range at manager initialization
> > advertising: Expose SupportedCapabilities for advertising
> > client: Add SupportedCapabilities to bluetoothctl
> > monitor: Add new MGMT adv commands and events to monitor
> >
> > client/main.c | 1 +
> > doc/advertising-api.txt | 50 +++++
> > doc/mgmt-api.txt | 238 +++++++++++++++++++++++-
> > lib/mgmt.h | 46 ++++-
> > monitor/packet.c | 69 ++++++-
> > src/adapter.c | 4 +
> > src/adapter.h | 1 +
> > src/advertising.c | 403 ++++++++++++++++++++++++++++++++++++++--
> > tools/btmgmt.c | 12 +-
> > 9 files changed, 791 insertions(+), 33 deletions(-)
> >
> > --
> > 2.28.0.709.gb0816b6eb0-goog
> >
Other than the small comments these look good to me.
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 18+ messages in thread