Re: [RFC BlueZ] Bluetooth: Add support for Mesh Scanning and Sending

Hi Brian,

quoted

quoted

Adds two new MGMT Commands:
        - MESH_MODE - Enable Mesh Mode with either Active or Passive
        scanning for a list of AD Types (Mesh and/or Extended Mesh).

        - MESH_SEND - Send a requested Mesh Packet on a non-resolvable
        random address, perhaps with a specific fine-timed delay.

Adds one new MGMT Event:
        - MESH_DEVICE_FOUND - Returned when Mesh is enabled, and one of
          the requested AD Types is detected in an incoming
          Advertisement.

Signed-off-by: Brian Gix <redacted>
---
doc/mgmt-api.txt | 119 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 119 insertions(+)

diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index ebe56afa4..3c34d6fb9 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt

@@ -332,6 +332,7 @@ Read Controller Information Command
                15      Static Address
                16      PHY Configuration
                17      Wideband Speech
+               18      Mesh Mode

        This command generates a Command Complete event on success or
        a Command Status event on failure.

@@ -3858,6 +3859,90 @@ Add Advertisement Patterns Monitor With RSSI Threshold Command
                                Invalid Parameters

also introduce a Read Mesh Features command. And things like Available Slots should go there.

OK.

quoted

quoted

+Set controller to Mesh mode Command
+==============================================================
+
+       Command Code:           0x0057
+       Controller Index:       <controller id>
+       Command Parameters:     Enable (1 Octet)
+                               Active (1 Octet)
+                               AD Types { }
+       Return Parameters:      Available Slots (1 Octet)
+
+       This command Enables or Disables Mesh Mode. Mesh mode, when enabled
+       keeps the controller passivly or actively scanning for LE Advertising
+       messgaes. To enable Mesh, LE must be enabled.
+
+       The Active parameter when set to 0x01, will cause the controller to
+       perform active scanning, as opposed to passive scanning, when the
+       parameter is set to 0x00.
+
+       The AD Types parameter, if present, will filter Advertising and Scan
+       responses by AD type. reponses that do not contain at least one of the
+       requested AD types will be discarded. response results will be delivered
+       with the Mesh Device Found event.
+
+       This command may be called redundantly to switch between Active and
+       Passive scanning, without disabling Mesh mode. If Mesh mode is disabled,
+       all active outbound Mesh Packet Send requests will return fail codes.
+
+       The returned parameter Available Slots returns the number of
+       simultaneous outbound packets that may to queued for delivery.
+
+       Possible errors:        Failed
+                               Busy
+                               No Resources
+                               Invalid Parameters

I would call this Set Mesh Receiver. I think we are going to reconfigure this at runtime for different AD
types depending on our mode.

However I do not get the Active part. I don’t want any Mesh Receiver that set the device to active scan. That
is crazy. If you for some reason want active scanning, then enable the mesh receiver and start a discovery
procedure. If the mesh receiver is marked as active it should report out any mesh packet, no matter how it
got it. However for basic mesh operation we will do passive scanning.

OK. So the idea here is that when performing Extended Provisioning Scanning, we need to active scan and return
specific requested AD types to the Provisioner.  This is only done for a very brief time when finding devices
to provision, so that friendly names can be returned in scan response packets (in addition to the normal mesh
UUID and features).  Active scanning is never done at any other time.

and for that you better use Start Discovery etc. commands.

Otherwise we need a separate command. Starting an active scan is similar to creating a connection. You fundamentally go into a different mode that causes active radio activity. It needs to have a defined lifespan since it will cancel out all passive scanning that is going on otherwise.

quoted

We also need to introduce scanning parameters via the settings so that we can overwrite the defaults.

Like windows and periods?  or something more like channels?

Yep. You can not control channels.

quoted

I think trying to bundle receiving with sending is a bit pointless and too much of a policy. Let userspace
handle that.

Receiving and sending are distinct from each other except that I was not planning on allowing sending unless we
had enabled Mesh Receiving. There is no technical reason this will be neccessary if we add a "Get Mesh
Features" command that returns available send slots.

And I am saying we should allow sending while _not_ receiving. For debugging purposes or testing or just hacking this will be useful.

quoted

quoted

+
+
+Mesh Packet Send Command
+==============================================================
+
+       Command Code:           0x0058
+       Controller Index:       <controller id>
+       Command Parameters:     Reference (1 Octets)
+                               Instant (4 Octets)
+                               Delay (2 Octets)
+                               Count (1 Octets)
+                               Data { }
+       Return Parameters:      Status, Reference Value
+
+       This command sends a Mesh Packet as a NONCONN LE Advertisement. Mesh
+       mode must be enabled.
+
+       The Reference value is Host defined, and will be returned with the
+       status, so that the Host may have multiple requests outstanding at
+       the same time. The Reference value will not be interpretted by the
+       kernel.
+
+       The Instant parameter is used in combination with the Delay
+       parameter, to finely time the sending of the Advertising packet. It
+       should be set to the Instant value tag of a received incoming
+       Mesh Device Found Event. It is only useful in POLL-RESPONSE situations
+       where a response must be sent within a negotiated time window. The value
+       of the Instant parameter should not be interpreted by the host, and
+       only has meaning to the controller.
+
+       The Delay parameter, if 0x0000, will cause the packet to be sent
+       immediately, or at the earliest opportunity. If non-Zero, it will
+       attempt to send the packet the requested number of milliseconds after
+       the instant in time represented by the Instant parameter.
+
+       The Count parameter must be sent to a non-Zero value indicating the
+       number of times this packet will be sent before transmission completes.
+       If the Delay parameter is non-Zero, then Count must be 1 only.
+
+       The Data parameter is an octet array of the AD Type and Mesh Packet.
+
+       This command will return only after the outbound packet has been sent,
+       or it fails.
+
+       Possible errors:        Failed
+                               Busy
+                               No Resources
+                               Invalid Parameters
+
+

I would call this Transmit Mesh Packet.

For the Reference, I am not convinced it is a good idea to have this come from userspace. We have to take
extra care then of checking for duplicates or other weird things. Let the kernel just return a reference that
can be used. I also tend to call this Handle.

You are also missing then the Mesh Packet Transmission Complete event.

OK, I can rework this. I wasn't returning *anything* on the send request until the transmission was complete
(which is why I have no complete event) and also way I had user space tag it's own send requests. If kernel
handles the reference/handle then I will need to probably not only add a Complete event, but also a cancel
command.

Cancel command is a good idea.

quoted

I think we should also include the Address and Address_Type and let userspace generate these. Or at least
allow it specify one and only let the kernel generate one in case of BDADDR_ANY. I want to give this API a
chance to survive in case newer specs want to play with using RPAs.

OK. Would you be happy with the "standard" case being use space passes BDADDR_ANY and type BDADDR_LE_RANDOM
causing the kernel to generate the address?

Pretty much any BDADDR_ANY should force to generate a NRPA.

Regards

Marcel