linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add
@ 2020-09-25  1:13 Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 1/9] doc/advertising-api: update API with new interface Daniel Winkler
                   ` (8 more replies)
  0 siblings, 9 replies; 13+ messages in thread
From: Daniel Winkler @ 2020-09-25  1:13 UTC (permalink / raw)
  To: luiz.von.dentz
  Cc: linux-bluetooth, chromeos-bluetooth-upstreaming, Daniel Winkler

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 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 (9):
  doc/advertising-api: update API with new interface
  doc/mgmt-api: Add new MGMT interfaces to 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        | 229 +++++++++++++++++++++-
 lib/mgmt.h              |  47 ++++-
 monitor/packet.c        |  79 +++++++-
 src/adapter.c           |   4 +
 src/adapter.h           |   1 +
 src/advertising.c       | 423 ++++++++++++++++++++++++++++++++++++++--
 tools/btmgmt.c          |  12 +-
 9 files changed, 813 insertions(+), 33 deletions(-)

-- 
2.28.0.709.gb0816b6eb0-goog


^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bluez PATCH v3 1/9] doc/advertising-api: update API with new interface
  2020-09-25  1:13 [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
@ 2020-09-25  1:13 ` Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 2/9] doc/mgmt-api: Add new MGMT interfaces to mgmt-api Daniel Winkler
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 13+ messages in thread
From: Daniel Winkler @ 2020-09-25  1:13 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 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] 13+ messages in thread

* [Bluez PATCH v3 2/9] doc/mgmt-api: Add new MGMT interfaces to mgmt-api
  2020-09-25  1:13 [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 1/9] doc/advertising-api: update API with new interface Daniel Winkler
@ 2020-09-25  1:13 ` Daniel Winkler
  2020-09-25 17:58   ` Marcel Holtmann
  2020-09-25  1:13 ` [Bluez PATCH v3 3/9] advertising: Detect if extended advertising mgmt commands are supported Daniel Winkler
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 13+ messages in thread
From: Daniel Winkler @ 2020-09-25  1:13 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
- Changes Read Security Info to Read Controller Capabilities CMD

Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
Reviewed-by: Alain Michaud <alainm@chromium.org>
---

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 | 229 +++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 223 insertions(+), 6 deletions(-)

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index ca0d38469..85aa8b797 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,8 @@ Read Security Information Command
 		0x01		Flags
 		0x02		Max Encryption Key Size (BR/EDR)
 		0x03		Max Encryption Key Size (LE)
+		0x04		Min Supported LE Tx Power (dBm)
+		0x05		Max Supported LE Tx Power (dBm)
 
 	Flags (data type 0x01)
 
@@ -3146,6 +3148,15 @@ Read Security Information Command
 		present, then it is unknown what the max encryption key
 		size of the controller or host is in use.
 
+	Min/Max Supported LE Tx Power (data types 0x04 and 0x05)
+
+		These fields indicate the supported range of LE Tx Power in
+		dBm across all supported PHYs. These values are populated
+		by the return of the LE Read Transmit Power HCI command. If
+		this HCI command is not available, the values default to
+		0x7F, indicating HCI_TX_POWER_INVALID, as a valid range
+		is not available.
+
 	This command generates a Command Complete event on success or
 	a Command Status event on failure.
 
@@ -3574,6 +3585,212 @@ 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)
+
+	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
+
+	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 Params member is 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 Params bit field uses the following bit to parameter relationship:
+
+		0	The Duration parameter should be used
+		1	The Timeout parameter should be used
+		2	The Interval parameters should be used
+		3	The Tx Power parameter should be used
+
+	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.
+
+	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.
+
+	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
 ======================
 
@@ -4576,4 +4793,4 @@ Advertisement Monitor Removed Event
 	using the Remove Advertisement Monitor command.
 
 	The event will only be sent to management sockets other than the
-	one through which the command was sent.
+	one through which the command was sent.
\ No newline at end of file
-- 
2.28.0.709.gb0816b6eb0-goog


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [Bluez PATCH v3 3/9] advertising: Detect if extended advertising mgmt commands are supported
  2020-09-25  1:13 [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 1/9] doc/advertising-api: update API with new interface Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 2/9] doc/mgmt-api: Add new MGMT interfaces to mgmt-api Daniel Winkler
@ 2020-09-25  1:13 ` Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 4/9] advertising: Parse intervals and tx power from adv Daniel Winkler
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 13+ messages in thread
From: Daniel Winkler @ 2020-09-25  1:13 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 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 | 5 +++++
 3 files changed, 10 insertions(+)

diff --git a/src/adapter.c b/src/adapter.c
index b2bd8b3f1..7811122c4 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -9653,6 +9653,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 b4d872b15..99802e287 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -246,6 +246,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 e5f25948d..f7b379b25 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -57,6 +57,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
@@ -1426,6 +1427,10 @@ 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);
+	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),
-- 
2.28.0.709.gb0816b6eb0-goog


^ permalink raw reply related	[flat|nested] 13+ messages in thread

* [Bluez PATCH v3 4/9] advertising: Parse intervals and tx power from adv
  2020-09-25  1:13 [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
                   ` (2 preceding siblings ...)
  2020-09-25  1:13 ` [Bluez PATCH v3 3/9] advertising: Detect if extended advertising mgmt commands are supported Daniel Winkler
@ 2020-09-25  1:13 ` Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 5/9] advertising: Use new mgmt interface for advertising add Daniel Winkler
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 13+ messages in thread
From: Daniel Winkler @ 2020-09-25  1:13 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 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 f7b379b25..c2de9fa2f 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -63,6 +63,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;
@@ -83,6 +88,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 {
@@ -946,6 +954,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);
@@ -964,6 +1040,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 },
 	{ },
 };
 
@@ -1092,6 +1171,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;
@@ -1167,6 +1253,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] 13+ messages in thread

* [Bluez PATCH v3 5/9] advertising: Use new mgmt interface for advertising add
  2020-09-25  1:13 [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
                   ` (3 preceding siblings ...)
  2020-09-25  1:13 ` [Bluez PATCH v3 4/9] advertising: Parse intervals and tx power from adv Daniel Winkler
@ 2020-09-25  1:13 ` Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 6/9] advertising: Query LE TX range at manager initialization Daniel Winkler
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 13+ messages in thread
From: Daniel Winkler @ 2020-09-25  1:13 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 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 | 234 +++++++++++++++++++++++++++++++++++++++++++---
 3 files changed, 253 insertions(+), 17 deletions(-)

diff --git a/lib/mgmt.h b/lib/mgmt.h
index 46d894ae9..fa0c2b562 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -713,6 +713,38 @@ struct mgmt_rp_remove_adv_monitor {
 	uint16_t monitor_handle;
 } __packed;
 
+#define MGMT_ADV_PARAM_DURATION		(1 << 0)
+#define MGMT_ADV_PARAM_TIMEOUT		(1 << 1)
+#define MGMT_ADV_PARAM_INTERVALS	(1 << 2)
+#define MGMT_ADV_PARAM_TX_POWER		(1 << 3)
+
+#define MGMT_OP_ADD_EXT_ADV_PARAMS		0x0054
+struct mgmt_cp_add_ext_adv_params {
+	uint8_t		instance;
+	uint32_t	flags;
+	uint16_t	params;
+	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;
+} __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 bef134095..9350a6682 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -6992,8 +6992,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 c2de9fa2f..3a4379c64 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -91,6 +91,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 {
@@ -112,6 +113,17 @@ static bool match_client(const void *a, const void *b)
 	return true;
 }
 
+static bool match_client_by_instance(const void *a, const void *b)
+{
+	const struct btd_adv_client *client = a;
+	const uint8_t *instance = b;
+
+	if (client && client->instance == *instance)
+		return true;
+
+	return false;
+}
+
 static void client_free(void *data)
 {
 	struct btd_adv_client *client = data;
@@ -797,19 +809,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;
@@ -821,6 +823,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.");
@@ -873,6 +895,76 @@ 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.flags = htobl(flags);
+	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;
+		included_params |= MGMT_ADV_PARAM_DURATION;
+	}
+
+	if (client->min_interval && client->max_interval) {
+		cp.min_interval = client->min_interval;
+		cp.max_interval = client->max_interval;
+		included_params |= MGMT_ADV_PARAM_INTERVALS;
+	}
+
+	if (client->tx_power != ADV_TX_POWER_NO_PREFERENCE) {
+		cp.tx_power = client->tx_power;
+		included_params |= MGMT_ADV_PARAM_TX_POWER;
+	}
+
+	cp.params = included_params;
+
+	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;
@@ -883,7 +975,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;
 }
@@ -1057,7 +1149,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;
 		}
 	}
@@ -1120,6 +1213,111 @@ 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 > calc_max_adv_len(client, flags))) {
+		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) {
+		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;
@@ -1178,7 +1376,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;
 
@@ -1257,6 +1457,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:
@@ -1575,7 +1777,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] 13+ messages in thread

* [Bluez PATCH v3 6/9] advertising: Query LE TX range at manager initialization
  2020-09-25  1:13 [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
                   ` (4 preceding siblings ...)
  2020-09-25  1:13 ` [Bluez PATCH v3 5/9] advertising: Use new mgmt interface for advertising add Daniel Winkler
@ 2020-09-25  1:13 ` Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 7/9] advertising: Expose SupportedCapabilities for advertising Daniel Winkler
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 13+ messages in thread
From: Daniel Winkler @ 2020-09-25  1:13 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 v3: None
Changes in v2: None

 lib/mgmt.h        | 15 ++++++++----
 src/advertising.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++
 tools/btmgmt.c    | 12 +++++-----
 3 files changed, 78 insertions(+), 10 deletions(-)

diff --git a/lib/mgmt.h b/lib/mgmt.h
index fa0c2b562..baeb0d82b 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -608,10 +608,17 @@ 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_MIN		0x04
+#define MGMT_CAP_LE_TX_PWR_MAX		0x05
+
+#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 3a4379c64..48b3d78b8 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -58,6 +58,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
@@ -1699,6 +1701,58 @@ 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 %u != %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_MIN:
+			if ((tag_len - sizeof(tag_type)) !=
+					sizeof(manager->min_tx_power)) {
+				error("TX power had unexpected length %d",
+					tag_len);
+				break;
+			}
+			memcpy(&manager->min_tx_power, &ptr[offset], tag_len);
+			break;
+		case MGMT_CAP_LE_TX_PWR_MAX:
+			if ((tag_len - sizeof(tag_type)) !=
+					sizeof(manager->min_tx_power)) {
+				error("TX power had unexpected length %d",
+					tag_len);
+				break;
+			}
+			memcpy(&manager->max_tx_power, &ptr[offset], tag_len);
+			break;
+		}
+
+		/* 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)
 {
@@ -1738,6 +1792,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] 13+ messages in thread

* [Bluez PATCH v3 7/9] advertising: Expose SupportedCapabilities for advertising
  2020-09-25  1:13 [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
                   ` (5 preceding siblings ...)
  2020-09-25  1:13 ` [Bluez PATCH v3 6/9] advertising: Query LE TX range at manager initialization Daniel Winkler
@ 2020-09-25  1:13 ` Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 8/9] client: Add SupportedCapabilities to bluetoothctl Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 9/9] monitor: Add new MGMT adv commands and events to monitor Daniel Winkler
  8 siblings, 0 replies; 13+ messages in thread
From: Daniel Winkler @ 2020-09-25  1:13 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 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 48b3d78b8..9ab8842c8 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -1639,12 +1639,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] 13+ messages in thread

* [Bluez PATCH v3 8/9] client: Add SupportedCapabilities to bluetoothctl
  2020-09-25  1:13 [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
                   ` (6 preceding siblings ...)
  2020-09-25  1:13 ` [Bluez PATCH v3 7/9] advertising: Expose SupportedCapabilities for advertising Daniel Winkler
@ 2020-09-25  1:13 ` Daniel Winkler
  2020-09-25  1:13 ` [Bluez PATCH v3 9/9] monitor: Add new MGMT adv commands and events to monitor Daniel Winkler
  8 siblings, 0 replies; 13+ messages in thread
From: Daniel Winkler @ 2020-09-25  1:13 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 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 2b0243308..cb8ef54ad 100644
--- a/client/main.c
+++ b/client/main.c
@@ -954,6 +954,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] 13+ messages in thread

* [Bluez PATCH v3 9/9] monitor: Add new MGMT adv commands and events to monitor
  2020-09-25  1:13 [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
                   ` (7 preceding siblings ...)
  2020-09-25  1:13 ` [Bluez PATCH v3 8/9] client: Add SupportedCapabilities to bluetoothctl Daniel Winkler
@ 2020-09-25  1:13 ` Daniel Winkler
  8 siblings, 0 replies; 13+ messages in thread
From: Daniel Winkler @ 2020-09-25  1:13 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 v3:
- Removed Tx Power Selected MGMT event from monitor

Changes in v2: None

 monitor/packet.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 75 insertions(+)

diff --git a/monitor/packet.c b/monitor/packet.c
index 9350a6682..00bc165cc 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -11872,6 +11872,26 @@ static void mgmt_print_adv_flags(uint32_t flags)
 							" (0x%8.8x)", mask);
 }
 
+static const struct bitfield_data mgmt_adv_params_table[] = {
+	{  0, "Use Duration parameter"	},
+	{  1, "Use Timeout parameter"	},
+	{  2, "Use Interval parameters"	},
+	{  3, "Use TX Power parameter"	},
+	{ }
+};
+
+static void mgmt_print_adv_params(uint16_t flags)
+{
+	uint32_t mask;
+
+	print_field("Enabled parameters: 0x%4.4x", flags);
+
+	mask = print_bitfield(2, flags, mgmt_adv_params_table);
+	if (mask)
+		print_text(COLOR_UNKNOWN_ADV_FLAG, "  Unknown advertising param"
+							" (0x%8.8x)", mask);
+}
+
 static void mgmt_print_store_hint(uint8_t hint)
 {
 	const char *str;
@@ -13163,6 +13183,55 @@ 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 params = get_le16(data + 5);
+	uint16_t duration = get_le16(data + 7);
+	uint16_t timeout = get_le16(data + 9);
+	uint8_t *min_interval = (uint8_t *)(data + 11);
+	uint8_t *max_interval = (uint8_t *)(data + 15);
+	int8_t tx_power = get_s8(data + 19);
+
+	print_field("Instance: %u", instance);
+	mgmt_print_adv_flags(flags);
+	mgmt_print_adv_params(params);
+	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);
+
+	print_field("Instance: %u", instance);
+	print_power_level(tx_power, NULL);
+}
+
+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;
@@ -13395,6 +13464,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, 20, false,
+				mgmt_add_ext_adv_params_rsp, 2, 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] 13+ messages in thread

* Re: [Bluez PATCH v3 2/9] doc/mgmt-api: Add new MGMT interfaces to mgmt-api
  2020-09-25  1:13 ` [Bluez PATCH v3 2/9] doc/mgmt-api: Add new MGMT interfaces to mgmt-api Daniel Winkler
@ 2020-09-25 17:58   ` Marcel Holtmann
  2020-10-01  0:55     ` Daniel Winkler
  0 siblings, 1 reply; 13+ messages in thread
From: Marcel Holtmann @ 2020-09-25 17:58 UTC (permalink / raw)
  To: Daniel Winkler
  Cc: Luiz Augusto von Dentz, linux-bluetooth, CrosBT Upstreaming,
	Sonny Sasaka, Alain Michaud

Hi Daniel,

> This patch adds the following to mgmt-api:
> - Add Extended Advertising Parameters Command
> - Add Extended Advertising Data Command
> - Changes Read Security Info to Read Controller Capabilities CMD
> 
> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
> Reviewed-by: Alain Michaud <alainm@chromium.org>
> ---
> 
> 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 | 229 +++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 223 insertions(+), 6 deletions(-)
> 
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index ca0d38469..85aa8b797 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
> =================================

I am fine with the name. Just extend the === to match the text above.

> 
> 	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,8 @@ Read Security Information Command
> 		0x01		Flags
> 		0x02		Max Encryption Key Size (BR/EDR)
> 		0x03		Max Encryption Key Size (LE)
> +		0x04		Min Supported LE Tx Power (dBm)
> +		0x05		Max Supported LE Tx Power (dBm)

I would actually prefer if we put them into a 2 octet size value. So two times s8 fields. And then just call it "Supported Tx Power (LE)”.

> 
> 	Flags (data type 0x01)
> 
> @@ -3146,6 +3148,15 @@ Read Security Information Command
> 		present, then it is unknown what the max encryption key
> 		size of the controller or host is in use.
> 
> +	Min/Max Supported LE Tx Power (data types 0x04 and 0x05)
> +
> +		These fields indicate the supported range of LE Tx Power in
> +		dBm across all supported PHYs. These values are populated
> +		by the return of the LE Read Transmit Power HCI command. If
> +		this HCI command is not available, the values default to
> +		0x7F, indicating HCI_TX_POWER_INVALID, as a valid range
> +		is not available.
> +

Actually no. If the command is not available or failed, then this field will not be present. Clearly indicate the absence. The should be a clear difference if the command is not available and the controller returning -127.

Can we split this change into a separate patch please.

> 	This command generates a Command Complete event on success or
> 	a Command Status event on failure.
> 
> @@ -3574,6 +3585,212 @@ 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)

If we leave the Flags that tell what adv data and scan rsp data to add, then we should also return the leftover sizes of each fields so that the caller knows how much they can occupy. So that you don’t have to use Get Advertising Size Information command to get that information. We already know it at this point in time.

> +
> +	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
> +
> +	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 Params member is 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 Params bit field uses the following bit to parameter relationship:
> +
> +		0	The Duration parameter should be used
> +		1	The Timeout parameter should be used
> +		2	The Interval parameters should be used
> +		3	The Tx Power parameter should be used
> +
> +	The Duration parameter configures the length of an Instance. The
> +	value is in seconds. The default is 2 seconds.

Wouldn’t we just add this to Flags instead of yet another parameter?

> +
> +	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.

This can get tricky with Instance Added and Instance Removed events. We would have to describe on how that is handled.

> +
> +	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.
> +
> +	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
> ======================
> 
> @@ -4576,4 +4793,4 @@ Advertisement Monitor Removed Event
> 	using the Remove Advertisement Monitor command.
> 
> 	The event will only be sent to management sockets other than the
> -	one through which the command was sent.
> +	one through which the command was sent.

Please don’t add unrelated changes.

Regards

Marcel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Bluez PATCH v3 2/9] doc/mgmt-api: Add new MGMT interfaces to mgmt-api
  2020-09-25 17:58   ` Marcel Holtmann
@ 2020-10-01  0:55     ` Daniel Winkler
  2020-10-01  7:00       ` Marcel Holtmann
  0 siblings, 1 reply; 13+ messages in thread
From: Daniel Winkler @ 2020-10-01  0:55 UTC (permalink / raw)
  To: Marcel Holtmann
  Cc: Luiz Augusto von Dentz, linux-bluetooth, CrosBT Upstreaming,
	Sonny Sasaka, Alain Michaud

Hi Marcel, I've got a new series that I plan to send tomorrow that
addresses all comments except one, below:


On Fri, Sep 25, 2020 at 10:58 AM Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Daniel,
>
> > This patch adds the following to mgmt-api:
> > - Add Extended Advertising Parameters Command
> > - Add Extended Advertising Data Command
> > - Changes Read Security Info to Read Controller Capabilities CMD
> >
> > Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
> > Reviewed-by: Alain Michaud <alainm@chromium.org>
> > ---
> >
> > 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 | 229 +++++++++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 223 insertions(+), 6 deletions(-)
> >
> > diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> > index ca0d38469..85aa8b797 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
> > =================================
>
> I am fine with the name. Just extend the === to match the text above.
>
> >
> >       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,8 @@ Read Security Information Command
> >               0x01            Flags
> >               0x02            Max Encryption Key Size (BR/EDR)
> >               0x03            Max Encryption Key Size (LE)
> > +             0x04            Min Supported LE Tx Power (dBm)
> > +             0x05            Max Supported LE Tx Power (dBm)
>
> I would actually prefer if we put them into a 2 octet size value. So two times s8 fields. And then just call it "Supported Tx Power (LE)”.
>
> >
> >       Flags (data type 0x01)
> >
> > @@ -3146,6 +3148,15 @@ Read Security Information Command
> >               present, then it is unknown what the max encryption key
> >               size of the controller or host is in use.
> >
> > +     Min/Max Supported LE Tx Power (data types 0x04 and 0x05)
> > +
> > +             These fields indicate the supported range of LE Tx Power in
> > +             dBm across all supported PHYs. These values are populated
> > +             by the return of the LE Read Transmit Power HCI command. If
> > +             this HCI command is not available, the values default to
> > +             0x7F, indicating HCI_TX_POWER_INVALID, as a valid range
> > +             is not available.
> > +
>
> Actually no. If the command is not available or failed, then this field will not be present. Clearly indicate the absence. The should be a clear difference if the command is not available and the controller returning -127.
>
> Can we split this change into a separate patch please.
>
> >       This command generates a Command Complete event on success or
> >       a Command Status event on failure.
> >
> > @@ -3574,6 +3585,212 @@ 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)
>
> If we leave the Flags that tell what adv data and scan rsp data to add, then we should also return the leftover sizes of each fields so that the caller knows how much they can occupy. So that you don’t have to use Get Advertising Size Information command to get that information. We already know it at this point in time.

Hi Marcel, I am happy to add the remaining space available for
advertising and scan response data to the response here. However,
userspace already has a local function,
advertising.c:calc_max_adv_len(), that computes the losses caused by
these flags. I imagine that this feature will be useful for any other
application not using userspace bluez so I will add it to the
response, but at the moment userspace does not need it. Please let me
know if you have any further thoughts on this point.

Thanks,
Daniel

>
> > +
> > +     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
> > +
> > +     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 Params member is 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 Params bit field uses the following bit to parameter relationship:
> > +
> > +             0       The Duration parameter should be used
> > +             1       The Timeout parameter should be used
> > +             2       The Interval parameters should be used
> > +             3       The Tx Power parameter should be used
> > +
> > +     The Duration parameter configures the length of an Instance. The
> > +     value is in seconds. The default is 2 seconds.
>
> Wouldn’t we just add this to Flags instead of yet another parameter?
>
> > +
> > +     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.
>
> This can get tricky with Instance Added and Instance Removed events. We would have to describe on how that is handled.
>
> > +
> > +     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.
> > +
> > +     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
> > ======================
> >
> > @@ -4576,4 +4793,4 @@ Advertisement Monitor Removed Event
> >       using the Remove Advertisement Monitor command.
> >
> >       The event will only be sent to management sockets other than the
> > -     one through which the command was sent.
> > +     one through which the command was sent.
>
> Please don’t add unrelated changes.
>
> Regards
>
> Marcel
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Bluez PATCH v3 2/9] doc/mgmt-api: Add new MGMT interfaces to mgmt-api
  2020-10-01  0:55     ` Daniel Winkler
@ 2020-10-01  7:00       ` Marcel Holtmann
  0 siblings, 0 replies; 13+ messages in thread
From: Marcel Holtmann @ 2020-10-01  7:00 UTC (permalink / raw)
  To: Daniel Winkler
  Cc: Luiz Augusto von Dentz, linux-bluetooth, CrosBT Upstreaming,
	Sonny Sasaka, Alain Michaud

Hi Daniel,

>>> This patch adds the following to mgmt-api:
>>> - Add Extended Advertising Parameters Command
>>> - Add Extended Advertising Data Command
>>> - Changes Read Security Info to Read Controller Capabilities CMD
>>> 
>>> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
>>> Reviewed-by: Alain Michaud <alainm@chromium.org>
>>> ---
>>> 
>>> 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 | 229 +++++++++++++++++++++++++++++++++++++++++++++--
>>> 1 file changed, 223 insertions(+), 6 deletions(-)
>>> 
>>> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
>>> index ca0d38469..85aa8b797 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
>>> =================================
>> 
>> I am fine with the name. Just extend the === to match the text above.
>> 
>>> 
>>>      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,8 @@ Read Security Information Command
>>>              0x01            Flags
>>>              0x02            Max Encryption Key Size (BR/EDR)
>>>              0x03            Max Encryption Key Size (LE)
>>> +             0x04            Min Supported LE Tx Power (dBm)
>>> +             0x05            Max Supported LE Tx Power (dBm)
>> 
>> I would actually prefer if we put them into a 2 octet size value. So two times s8 fields. And then just call it "Supported Tx Power (LE)”.
>> 
>>> 
>>>      Flags (data type 0x01)
>>> 
>>> @@ -3146,6 +3148,15 @@ Read Security Information Command
>>>              present, then it is unknown what the max encryption key
>>>              size of the controller or host is in use.
>>> 
>>> +     Min/Max Supported LE Tx Power (data types 0x04 and 0x05)
>>> +
>>> +             These fields indicate the supported range of LE Tx Power in
>>> +             dBm across all supported PHYs. These values are populated
>>> +             by the return of the LE Read Transmit Power HCI command. If
>>> +             this HCI command is not available, the values default to
>>> +             0x7F, indicating HCI_TX_POWER_INVALID, as a valid range
>>> +             is not available.
>>> +
>> 
>> Actually no. If the command is not available or failed, then this field will not be present. Clearly indicate the absence. The should be a clear difference if the command is not available and the controller returning -127.
>> 
>> Can we split this change into a separate patch please.
>> 
>>>      This command generates a Command Complete event on success or
>>>      a Command Status event on failure.
>>> 
>>> @@ -3574,6 +3585,212 @@ 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)
>> 
>> If we leave the Flags that tell what adv data and scan rsp data to add, then we should also return the leftover sizes of each fields so that the caller knows how much they can occupy. So that you don’t have to use Get Advertising Size Information command to get that information. We already know it at this point in time.
> 
> Hi Marcel, I am happy to add the remaining space available for
> advertising and scan response data to the response here. However,
> userspace already has a local function,
> advertising.c:calc_max_adv_len(), that computes the losses caused by
> these flags. I imagine that this feature will be useful for any other
> application not using userspace bluez so I will add it to the
> response, but at the moment userspace does not need it. Please let me
> know if you have any further thoughts on this point.

I prefer that userspace does not have to guess or we have to keep kernel implementation in sync with usersapce. So if we tell userspace just what space it has available, that is cleaner.

Regards

Marcel


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2020-10-01  7:00 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-25  1:13 [Bluez PATCH v3 0/9] Bluetooth: Add new MGMT interface for advertising add Daniel Winkler
2020-09-25  1:13 ` [Bluez PATCH v3 1/9] doc/advertising-api: update API with new interface Daniel Winkler
2020-09-25  1:13 ` [Bluez PATCH v3 2/9] doc/mgmt-api: Add new MGMT interfaces to mgmt-api Daniel Winkler
2020-09-25 17:58   ` Marcel Holtmann
2020-10-01  0:55     ` Daniel Winkler
2020-10-01  7:00       ` Marcel Holtmann
2020-09-25  1:13 ` [Bluez PATCH v3 3/9] advertising: Detect if extended advertising mgmt commands are supported Daniel Winkler
2020-09-25  1:13 ` [Bluez PATCH v3 4/9] advertising: Parse intervals and tx power from adv Daniel Winkler
2020-09-25  1:13 ` [Bluez PATCH v3 5/9] advertising: Use new mgmt interface for advertising add Daniel Winkler
2020-09-25  1:13 ` [Bluez PATCH v3 6/9] advertising: Query LE TX range at manager initialization Daniel Winkler
2020-09-25  1:13 ` [Bluez PATCH v3 7/9] advertising: Expose SupportedCapabilities for advertising Daniel Winkler
2020-09-25  1:13 ` [Bluez PATCH v3 8/9] client: Add SupportedCapabilities to bluetoothctl Daniel Winkler
2020-09-25  1:13 ` [Bluez PATCH v3 9/9] monitor: Add new MGMT adv commands and events to monitor Daniel Winkler

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).