[Bluez PATCH v2 00/10] Bluetooth: Add new MGMT interface for advertising add

[Bluez PATCH v2 00/10] Bluetooth: Add new MGMT interface for advertising add

[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 v2:
- Removed extra space in Add Extended Advertising Parameters API
- Uses btd_has_kernel_features to detect kernel command support
- Cleaned fail path in add_adv_params_callback

Daniel Winkler (10):
  doc/advertising-api: update API with new interface
  doc/mgmt-api: Add new 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: Catch tx power selected event and handle it
  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        | 242 ++++++++++++++++++++++
 lib/mgmt.h              |  45 +++++
 monitor/packet.c        |  84 ++++++++
 src/adapter.c           |   4 +
 src/adapter.h           |   1 +
 src/advertising.c       | 433 ++++++++++++++++++++++++++++++++++++++--
 8 files changed, 845 insertions(+), 15 deletions(-)

-- 
2.28.0.681.g6f77f65b4e-goog

[Bluez PATCH v2 01/10] doc/advertising-api: update API with new interface

[Daniel Winkler]

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 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.681.g6f77f65b4e-goog

[Bluez PATCH v2 02/10] doc/mgmt-api: Add new MGMT interfaces to mgmt-api

[Daniel Winkler]

This patch adds the following to mgmt-api:
- Add Extended Advertising Parameters Command
- Add Extended Advertising Data Command
- Read Controller Capabilities Command
- Advertisement Tx Power Selected Event

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

Changes in v2:
- Removed extra space in Add Extended Advertising Parameters API

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

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index ca0d38469..62f976a11 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -3574,6 +3574,234 @@ 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)
+
+	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, but the caller can determine the power
+	chosen by the controller by listening for the Tx Power Selected MGMT
+	event that follows this command. 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
+
+
+Read Controller Capabilities Command
+====================================
+
+	Command Code:		0x0056
+	Controller Index:	<controller id>
+	Command Parameters:
+	Return Parameters:	Parameter1 {
+					Capability_Tag (2 Octet)
+					Value_Length (1 Octet)
+					Value (0-255 Octets)
+				}
+				Parameter2 { }
+				...
+
+	This command is used to read a list of controller capabilities.
+
+	Currently defined Capability_Tag values are:
+
+		0x0000	Minimum Supported LE Tx Power (dBm)
+		0x0001	Maximum Supported LE Tx Power (dBm)
+
+
 Command Complete Event
 ======================
 
@@ -4577,3 +4805,17 @@ Advertisement Monitor Removed Event
 
 	The event will only be sent to management sockets other than the
 	one through which the command was sent.
+
+
+Advertisement Tx Power Selected Event
+===================================
+
+	Event Code:		0x002d
+	Controller Index:	<controller id>
+	Event Parameters:	Instance (1 Octet)
+				TxPower (1 Octet)
+
+	This event indicates that the controller selected a transmission
+	power for an advertising instance. The event is emitted on platforms
+	that support extended advertising after an Add Extended Advertising
+	Parameters command is submitted.
\ No newline at end of file
-- 
2.28.0.681.g6f77f65b4e-goog

[Bluez PATCH v2 03/10] advertising: Detect if extended advertising mgmt commands are supported

[Daniel Winkler]

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 v2:
- Uses btd_has_kernel_features to detect kernel command support

 src/adapter.c     | 4 ++++
 src/adapter.h     | 1 +
 src/advertising.c | 3 +++
 3 files changed, 8 insertions(+)

diff --git a/src/adapter.c b/src/adapter.c
index 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..ad2eeefb9 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,8 @@ static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
 	manager->mgmt_index = btd_adapter_get_index(adapter);
 	manager->clients = queue_new();
 	manager->supported_flags = MGMT_ADV_FLAG_LOCAL_NAME;
+	manager->extended_add_cmds =
+			btd_has_kernel_features(KERNEL_HAS_EXT_ADV_ADD_CMDS);
 
 	if (!g_dbus_register_interface(btd_get_dbus_connection(),
 					adapter_get_path(manager->adapter),
-- 
2.28.0.681.g6f77f65b4e-goog

[Bluez PATCH v2 04/10] advertising: Parse intervals and tx power from adv

[Daniel Winkler]

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 v2: None

 src/advertising.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 89 insertions(+)

diff --git a/src/advertising.c b/src/advertising.c
index ad2eeefb9..3c173fef0 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 (%u > %u)",
+				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.681.g6f77f65b4e-goog

[Bluez PATCH v2 05/10] advertising: Use new mgmt interface for advertising add

[Daniel Winkler]

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.

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 v2:
- Cleaned fail path in add_adv_params_callback

 lib/mgmt.h        |  31 +++++++
 src/advertising.c | 216 ++++++++++++++++++++++++++++++++++++++++++----
 2 files changed, 232 insertions(+), 15 deletions(-)

diff --git a/lib/mgmt.h b/lib/mgmt.h
index 46d894ae9..9874be004 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -713,6 +713,37 @@ 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;
+} __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/src/advertising.c b/src/advertising.c
index 3c173fef0..cab0b79de 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 {
@@ -797,19 +798,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 +812,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 +884,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 +964,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 +1138,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 +1202,104 @@ 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;
+
+	if (status)
+		goto fail;
+
+	if (!param || length < sizeof(*rp)) {
+		status = MGMT_STATUS_FAILED;
+		goto fail;
+	}
+
+	DBG("Refreshing advertisement data: %s", client->path);
+
+	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 +1358,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 +1439,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:
@@ -1573,7 +1757,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.681.g6f77f65b4e-goog

[Bluez PATCH v2 06/10] advertising: Catch tx power selected event and handle it

[Daniel Winkler]

The new Tx Power Selected MGMT event will alert bluetoothd that an
advertising instance has been assigned a tx power. This is intended to
be used to then update the client of their instance's tx power.

Towards this goal, this patch does the following:
- When adv manager is created, register a handler for tx selected event
- On callback, identify the relevant advertising instance, and call for
  a property set with the new value. If the client exposes this method,
  it will be called with the new value selected by the controller.

To test, I modified the example-advertisement python script to implement
the Set dbus method, and verified that it is called after advertisement
registration on a device with extended advertising.

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

Changes in v2: None

 lib/mgmt.h        |  6 ++++++
 src/advertising.c | 32 ++++++++++++++++++++++++++++++++
 2 files changed, 38 insertions(+)

diff --git a/lib/mgmt.h b/lib/mgmt.h
index 9874be004..56f46ce93 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -1002,6 +1002,12 @@ struct mgmt_ev_controller_resume {
 	uint8_t wake_reason;
 } __packed;
 
+#define MGMT_EV_ADV_TX_POWER_SELECTED	0x002f
+struct mgmt_ev_adv_tx_power_selected {
+	uint8_t	instance;
+	int8_t	tx_power;
+} __packed;
+
 static const char *mgmt_op[] = {
 	"<0x0000>",
 	"Read Version",
diff --git a/src/advertising.c b/src/advertising.c
index cab0b79de..c7deda1ad 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -113,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;
@@ -1681,6 +1692,22 @@ static void read_adv_features_callback(uint8_t status, uint16_t length,
 		remove_advertising(manager, 0);
 }
 
+static void tx_power_selected(uint16_t index, uint16_t length,
+					const void *param, void *user_data)
+{
+	const struct mgmt_ev_adv_tx_power_selected *ev = param;
+	struct btd_adv_client *client;
+	struct btd_adv_manager *manager = user_data;
+	dbus_int16_t tx_power = ev->tx_power;
+
+	client = queue_find(manager->clients, match_client_by_instance,
+			&ev->instance);
+
+	if (client)
+		g_dbus_proxy_set_property_basic(client->proxy, "TxPower",
+				DBUS_TYPE_INT16, &tx_power, NULL, NULL, NULL);
+}
+
 static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
 						struct mgmt *mgmt)
 {
@@ -1718,6 +1745,11 @@ static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
 		goto fail;
 	}
 
+	if (manager->extended_add_cmds)
+		mgmt_register(manager->mgmt, MGMT_EV_ADV_TX_POWER_SELECTED,
+			      manager->mgmt_index, tx_power_selected,
+			      manager, NULL);
+
 	return manager;
 
 fail:
-- 
2.28.0.681.g6f77f65b4e-goog

[Bluez PATCH v2 07/10] advertising: Query LE TX range at manager initialization

[Daniel Winkler]

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 v2: None

 lib/mgmt.h        |  8 +++++++
 src/advertising.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+)

diff --git a/lib/mgmt.h b/lib/mgmt.h
index 56f46ce93..558452e9c 100644
--- a/lib/mgmt.h
+++ b/lib/mgmt.h
@@ -744,6 +744,14 @@ struct mgmt_rp_add_ext_adv_data {
 	uint8_t	instance;
 } __packed;
 
+#define MGMT_CAP_LE_TX_PWR_MIN	0x0000
+#define MGMT_CAP_LE_TX_PWR_MAX	0x0001
+
+#define MGMT_OP_READ_CONTROLLER_CAP	0x0056
+struct mgmt_rp_read_controller_cap {
+	uint8_t capabilities[0]; /* mgmt_tlv */
+} __packed;
+
 #define MGMT_EV_CMD_COMPLETE		0x0001
 struct mgmt_ev_cmd_complete {
 	uint16_t opcode;
diff --git a/src/advertising.c b/src/advertising.c
index c7deda1ad..a3e7f3d59 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
@@ -1708,6 +1710,54 @@ static void tx_power_selected(uint16_t index, uint16_t length,
 				DBUS_TYPE_INT16, &tx_power, NULL, NULL, NULL);
 }
 
+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 uint8_t *ptr = param;
+	uint16_t offset = 0;
+
+	/* Both capabilities we care about are stored as int8_t. If we later
+	 * want to track other types, this structure will need to change
+	 */
+	const struct {
+		struct mgmt_tlv entry;
+		int8_t value;
+	} __packed * cap;
+
+	while (offset < length) {
+		/* Since TLV entries can have variable length, offset tracks how
+		 * far into the member we are, so that cap is always pointing
+		 * to the beginning of a valid struct
+		 */
+		cap = (void *)&ptr[offset];
+		switch (cap->entry.type) {
+		case MGMT_CAP_LE_TX_PWR_MIN:
+			if (cap->entry.length !=
+					sizeof(manager->min_tx_power)) {
+				error("TX power had unexpected length %d",
+					cap->entry.length);
+				break;
+			}
+			memcpy(&manager->min_tx_power, &cap->value,
+					cap->entry.length);
+			break;
+		case MGMT_CAP_LE_TX_PWR_MAX:
+			if (cap->entry.length !=
+					sizeof(manager->min_tx_power)) {
+				error("TX power had unexpected length %d",
+					cap->entry.length);
+				break;
+			}
+			memcpy(&manager->max_tx_power, &cap->value,
+					cap->entry.length);
+			break;
+		}
+
+		offset += sizeof(cap->entry) + cap->entry.length;
+	}
+}
+
 static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
 						struct mgmt *mgmt)
 {
@@ -1729,6 +1779,8 @@ static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
 	manager->supported_flags = MGMT_ADV_FLAG_LOCAL_NAME;
 	manager->extended_add_cmds =
 			btd_has_kernel_features(KERNEL_HAS_EXT_ADV_ADD_CMDS);
+	manager->min_tx_power = ADV_TX_POWER_NO_PREFERENCE;
+	manager->max_tx_power = ADV_TX_POWER_NO_PREFERENCE;
 
 	if (!g_dbus_register_interface(btd_get_dbus_connection(),
 					adapter_get_path(manager->adapter),
@@ -1750,6 +1802,13 @@ static struct btd_adv_manager *manager_create(struct btd_adapter *adapter,
 			      manager->mgmt_index, tx_power_selected,
 			      manager, NULL);
 
+	/* 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:
-- 
2.28.0.681.g6f77f65b4e-goog

[Bluez PATCH v2 08/10] advertising: Expose SupportedCapabilities for advertising

[Daniel Winkler]

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 v2: None

 src/advertising.c | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/src/advertising.c b/src/advertising.c
index a3e7f3d59..a736c409f 100644
--- a/src/advertising.c
+++ b/src/advertising.c
@@ -1632,12 +1632,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.681.g6f77f65b4e-goog

[Bluez PATCH v2 09/10] client: Add SupportedCapabilities to bluetoothctl

[Daniel Winkler]

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 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.681.g6f77f65b4e-goog

[Bluez PATCH v2 10/10] monitor: Add new MGMT adv commands and events to monitor

[Daniel Winkler]

This change adds the following to packet monitor:
-Add Ext Adv Params command and response
-Add Ext Adv Data command and response
-Add Advertising Power Selected event

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 v2: None

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

diff --git a/monitor/packet.c b/monitor/packet.c
index bef134095..5d1e6868e 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,53 @@ 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);
+	uint32_t min_interval = get_le32(data + 11);
+	uint32_t max_interval = get_le32(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);
+
+	print_field("Instance: %u", instance);
+}
+
+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 +13462,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, 1, true },
+	{ 0x0055, "Add Ext Adv Data",
+				mgmt_add_ext_adv_data_cmd, 3, false,
+				mgmt_add_ext_adv_data_rsp, 1, true },
 	{ }
 };
 
@@ -13847,6 +13920,15 @@ static void mgmt_controller_resume_evt(const void *data, uint16_t size)
 	mgmt_print_address(data, addr_type);
 }
 
+static void mgmt_adv_power_selected_evt(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 const struct mgmt_data mgmt_event_table[] = {
 	{ 0x0001, "Command Complete",
 			mgmt_command_complete_evt, 3, false },
@@ -13932,6 +14014,8 @@ static const struct mgmt_data mgmt_event_table[] = {
 			mgmt_controller_suspend_evt, 1, true },
 	{ 0x002e, "Controller Resumed",
 			mgmt_controller_resume_evt, 8, true },
+	{ 0x002f, "Advertising Power Selected",
+			mgmt_adv_power_selected_evt, 2, true },
 	{ }
 };
 
-- 
2.28.0.681.g6f77f65b4e-goog

Re: [Bluez PATCH v2 02/10] doc/mgmt-api: Add new MGMT interfaces to mgmt-api

[Marcel Holtmann]

Hi Daniel,

> This patch adds the following to mgmt-api:
> - Add Extended Advertising Parameters Command
> - Add Extended Advertising Data Command
> - Read Controller Capabilities Command
> - Advertisement Tx Power Selected Event
> 
> Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
> Reviewed-by: Alain Michaud <alainm@chromium.org>
> ---
> 
> Changes in v2:
> - Removed extra space in Add Extended Advertising Parameters API
> 
> doc/mgmt-api.txt | 242 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 242 insertions(+)
> 
> diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> index ca0d38469..62f976a11 100644
> --- a/doc/mgmt-api.txt
> +++ b/doc/mgmt-api.txt
> @@ -3574,6 +3574,234 @@ 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)

didn’t you also want to return the selected TxPower? We then also have to agree to allow this command only when the controller is powered.

> +
> +	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, but the caller can determine the power
> +	chosen by the controller by listening for the Tx Power Selected MGMT
> +	event that follows this command. 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
> +
> +
> +Read Controller Capabilities Command
> +====================================
> +
> +	Command Code:		0x0056
> +	Controller Index:	<controller id>
> +	Command Parameters:
> +	Return Parameters:	Parameter1 {
> +					Capability_Tag (2 Octet)
> +					Value_Length (1 Octet)
> +					Value (0-255 Octets)
> +				}
> +				Parameter2 { }
> +				...
> +
> +	This command is used to read a list of controller capabilities.
> +
> +	Currently defined Capability_Tag values are:
> +
> +		0x0000	Minimum Supported LE Tx Power (dBm)
> +		0x0001	Maximum Supported LE Tx Power (dBm)
> +
> +

I was thinking we rename Read Security Information Command and also return these values there. I think it is a bit of waste to introduce yet another command to return controller capabilities.

> Command Complete Event
> ======================
> 
> @@ -4577,3 +4805,17 @@ Advertisement Monitor Removed Event
> 
> 	The event will only be sent to management sockets other than the
> 	one through which the command was sent.
> +
> +
> +Advertisement Tx Power Selected Event
> +===================================
> +
> +	Event Code:		0x002d
> +	Controller Index:	<controller id>
> +	Event Parameters:	Instance (1 Octet)
> +				TxPower (1 Octet)
> +
> +	This event indicates that the controller selected a transmission
> +	power for an advertising instance. The event is emitted on platforms
> +	that support extended advertising after an Add Extended Advertising
> +	Parameters command is submitted.

I would rather return the value right away and only allow it when powered on.

Regards

Marcel

Re: [Bluez PATCH v2 02/10] doc/mgmt-api: Add new MGMT interfaces to mgmt-api

[Daniel Winkler]

Hello Marcel, thank you very much for the feedback! Some responses below:

> I would rather return the value right away and only allow it when powered on.

I have already imposed a "powered" requirement for both MGMT
advertising commands and in the documentation here. In our discussions
regarding this feature, we had chosen to emit a Tx Power Selected
event because these "extended" advertising commands may be used even
on platforms without controller support for extended advertising
features. In other words, we thought it would make more sense to emit
a Tx Power Selected event when relevant, rather than always returning
a Tx power in the MGMT response, even if it is not relevant. If you
think I should return the selected Tx Power directly, I can do so.
Perhaps we can populate the response with
HCI_ADV_TX_POWER_NO_PREFERENCE if extended advertising is not
available. Please let me know your thoughts.

> I was thinking we rename Read Security Information Command and also return these values there. I think it is a bit of waste to introduce yet another command to return controller capabilities.

My mistake, I was under the impression that you preferred adding a new
command. I will look into adding the new Tx power range parameters to
the "Read Security Information Command". Please let me know your
preferred new name for the command.

Thank you in advance for your help!

Best,
Daniel Winkler

On Sat, Sep 19, 2020 at 11:07 PM 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
> > - Read Controller Capabilities Command
> > - Advertisement Tx Power Selected Event
> >
> > Reviewed-by: Sonny Sasaka <sonnysasaka@chromium.org>
> > Reviewed-by: Alain Michaud <alainm@chromium.org>
> > ---
> >
> > Changes in v2:
> > - Removed extra space in Add Extended Advertising Parameters API
> >
> > doc/mgmt-api.txt | 242 +++++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 242 insertions(+)
> >
> > diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
> > index ca0d38469..62f976a11 100644
> > --- a/doc/mgmt-api.txt
> > +++ b/doc/mgmt-api.txt
> > @@ -3574,6 +3574,234 @@ 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)
>
> didn’t you also want to return the selected TxPower? We then also have to agree to allow this command only when the controller is powered.
>
> > +
> > +     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, but the caller can determine the power
> > +     chosen by the controller by listening for the Tx Power Selected MGMT
> > +     event that follows this command. 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
> > +
> > +
> > +Read Controller Capabilities Command
> > +====================================
> > +
> > +     Command Code:           0x0056
> > +     Controller Index:       <controller id>
> > +     Command Parameters:
> > +     Return Parameters:      Parameter1 {
> > +                                     Capability_Tag (2 Octet)
> > +                                     Value_Length (1 Octet)
> > +                                     Value (0-255 Octets)
> > +                             }
> > +                             Parameter2 { }
> > +                             ...
> > +
> > +     This command is used to read a list of controller capabilities.
> > +
> > +     Currently defined Capability_Tag values are:
> > +
> > +             0x0000  Minimum Supported LE Tx Power (dBm)
> > +             0x0001  Maximum Supported LE Tx Power (dBm)
> > +
> > +
>
> I was thinking we rename Read Security Information Command and also return these values there. I think it is a bit of waste to introduce yet another command to return controller capabilities.
>
> > Command Complete Event
> > ======================
> >
> > @@ -4577,3 +4805,17 @@ Advertisement Monitor Removed Event
> >
> >       The event will only be sent to management sockets other than the
> >       one through which the command was sent.
> > +
> > +
> > +Advertisement Tx Power Selected Event
> > +===================================
> > +
> > +     Event Code:             0x002d
> > +     Controller Index:       <controller id>
> > +     Event Parameters:       Instance (1 Octet)
> > +                             TxPower (1 Octet)
> > +
> > +     This event indicates that the controller selected a transmission
> > +     power for an advertising instance. The event is emitted on platforms
> > +     that support extended advertising after an Add Extended Advertising
> > +     Parameters command is submitted.
>
> I would rather return the value right away and only allow it when powered on.
>
> Regards
>
> Marcel
>

Re: [Bluez PATCH v2 02/10] doc/mgmt-api: Add new MGMT interfaces to mgmt-api

[Marcel Holtmann]

Hi Daniel,

> I have already imposed a "powered" requirement for both MGMT
> advertising commands and in the documentation here. In our discussions
> regarding this feature, we had chosen to emit a Tx Power Selected
> event because these "extended" advertising commands may be used even
> on platforms without controller support for extended advertising
> features. In other words, we thought it would make more sense to emit
> a Tx Power Selected event when relevant, rather than always returning
> a Tx power in the MGMT response, even if it is not relevant. If you
> think I should return the selected Tx Power directly, I can do so.
> Perhaps we can populate the response with
> HCI_ADV_TX_POWER_NO_PREFERENCE if extended advertising is not
> available. Please let me know your thoughts.

I would prefer to directly return Selected_TX_Power value since then you know for sure that the controller has chosen one or does not support it (for that use -127 / TX_POWER_INVALID as value). It has the advantage that you clearly know what you have. Otherwise we have to wait and hope for an event that might come or might not come. Meaning we have to start a timer in userspace and handle the case when it doesn’t come. So I think just return the value and we set it to INVALID if we don’t have it.

>> I was thinking we rename Read Security Information Command and also return these values there. I think it is a bit of waste to introduce yet another command to return controller capabilities.
> 
> My mistake, I was under the impression that you preferred adding a new
> command. I will look into adding the new Tx power range parameters to
> the "Read Security Information Command". Please let me know your
> preferred new name for the command.

Maybe we keep it simple as “Read Controller Features” command.

Regards

Marcel