michaelh/zephyr
1
0
Fork 0
Code Releases Activity

bluetooth: mesh: Doc fix Bluetooth mesh to Mesh

Browse source 
SIG has changed Bluetooth mesh to Bluetooth Mesh
Updating zephyr docs accordingly
Leaving out old release notes

Signed-off-by: Mia Koen <mia.koen@nordicsemi.no>
This commit is contained in:
Mia Koen 2023-11-29 13:33:33 +01:00 • committed by Fabio Baltieri
commit 0bcad09392
60 changed files with 140 additions and 140 deletions
Download patch file Download diff file Expand all files Collapse all files

2
boards/arm/nrf52840_mdk/doc/index.rst
View file

@ -7,7 +7,7 @@ Overview
******** ********
The nRF52840-MDK is a versatile, easy-to-use IoT hardware platform for The nRF52840-MDK is a versatile, easy-to-use IoT hardware platform for
Bluetooth 5, Bluetooth mesh, Thread, IEEE 802.15.4, ANT and 2.4GHz proprietary Bluetooth 5, Bluetooth Mesh, Thread, IEEE 802.15.4, ANT and 2.4GHz proprietary
applications using the nRF52840 SoC. applications using the nRF52840 SoC.
The development kit comes with a fully integrated debugger (also known as The development kit comes with a fully integrated debugger (also known as

2
boards/riscv/esp32c3_devkitm/doc/index.rst
View file

@ -18,7 +18,7 @@ The features include the following:
- 32-bit core RISC-V microcontroller with a maximum clock speed of 160 MHz - 32-bit core RISC-V microcontroller with a maximum clock speed of 160 MHz
- 400 KB of internal RAM - 400 KB of internal RAM
- 802.11b/g/n/e/i - 802.11b/g/n/e/i
- A Bluetooth LE subsystem that supports features of Bluetooth 5 and Bluetooth mesh - A Bluetooth LE subsystem that supports features of Bluetooth 5 and Bluetooth Mesh
- Various peripherals: - Various peripherals:
- 12-bit ADC with up to 6 channels - 12-bit ADC with up to 6 channels

2
boards/riscv/esp32c3_luatos_core/doc/index.rst
View file

@ -18,7 +18,7 @@ The features include the following:
- 32-bit core RISC-V microcontroller with a maximum clock speed of 160 MHz - 32-bit core RISC-V microcontroller with a maximum clock speed of 160 MHz
- 400 KB of internal RAM - 400 KB of internal RAM
- 802.11b/g/n/e/i - 802.11b/g/n/e/i
- A Bluetooth LE subsystem that supports features of Bluetooth 5 and Bluetooth mesh - A Bluetooth LE subsystem that supports features of Bluetooth 5 and Bluetooth Mesh
- Various peripherals: - Various peripherals:
- 12-bit ADC with up to 6 channels - 12-bit ADC with up to 6 channels

4
doc/connectivity/bluetooth/api/mesh.rst
View file

@ -3,14 +3,14 @@
Bluetooth Mesh Profile Bluetooth Mesh Profile
###################### ######################
The Bluetooth mesh profile adds secure wireless multi-hop communication for The Bluetooth Mesh profile adds secure wireless multi-hop communication for
Bluetooth Low Energy. This module implements the Bluetooth Low Energy. This module implements the
`Bluetooth Mesh Profile Specification v1.0.1 <https://www.bluetooth.com/specifications/specs/mesh-profile-1-0-1/>`_. `Bluetooth Mesh Profile Specification v1.0.1 <https://www.bluetooth.com/specifications/specs/mesh-profile-1-0-1/>`_.
Implementation of the `Bluetooth Mesh Protocol Specification v1.1 <https://www.bluetooth.com/specifications/specs/mesh-protocol/>`_ Implementation of the `Bluetooth Mesh Protocol Specification v1.1 <https://www.bluetooth.com/specifications/specs/mesh-protocol/>`_
is in experimental state. is in experimental state.
Read more about Bluetooth mesh on the Read more about Bluetooth Mesh on the
`Bluetooth SIG Website <https://www.bluetooth.com/bluetooth-resources/?tags=mesh>`_. `Bluetooth SIG Website <https://www.bluetooth.com/bluetooth-resources/?tags=mesh>`_.
.. toctree:: .. toctree::

4
doc/connectivity/bluetooth/api/mesh/access.rst
View file

@ -3,7 +3,7 @@
Access layer Access layer
############ ############
The access layer is the application's interface to the Bluetooth mesh network. The access layer is the application's interface to the Bluetooth Mesh network.
The access layer provides mechanisms for compartmentalizing the node behavior The access layer provides mechanisms for compartmentalizing the node behavior
into elements and models, which are implemented by the application. into elements and models, which are implemented by the application.
@ -113,7 +113,7 @@ number within one publication interval.
Extended models Extended models
=============== ===============
The Bluetooth mesh specification allows the mesh models to extend each other. The Bluetooth Mesh specification allows the mesh models to extend each other.
When a model extends another, it inherits that model's functionality, and When a model extends another, it inherits that model's functionality, and
extension can be used to construct complex models out of simple ones, extension can be used to construct complex models out of simple ones,
leveraging the existing model functionality to avoid defining new opcodes. leveraging the existing model functionality to avoid defining new opcodes.

6
doc/connectivity/bluetooth/api/mesh/blob.rst
View file

@ -5,7 +5,7 @@ BLOB Transfer models
The Binary Large Object (BLOB) Transfer models implement the Bluetooth Mesh Binary Large Object The Binary Large Object (BLOB) Transfer models implement the Bluetooth Mesh Binary Large Object
Transfer Model specification version 1.0 and provide functionality for sending large binary objects Transfer Model specification version 1.0 and provide functionality for sending large binary objects
from a single source to many Target nodes over the Bluetooth mesh network. It is the underlying from a single source to many Target nodes over the Bluetooth Mesh network. It is the underlying
transport method for the :ref:`bluetooth_mesh_dfu`, but may be used for other object transfer transport method for the :ref:`bluetooth_mesh_dfu`, but may be used for other object transfer
purposes. The implementation is in experimental state. purposes. The implementation is in experimental state.
@ -50,7 +50,7 @@ structure of the BLOB, and applications are free to define any encoding or compr
on the data itself. on the data itself.
The BLOB transfer protocol does not provide any built-in integrity checks, encryption or The BLOB transfer protocol does not provide any built-in integrity checks, encryption or
authentication of the BLOB data. However, the underlying encryption of the Bluetooth mesh protocol authentication of the BLOB data. However, the underlying encryption of the Bluetooth Mesh protocol
provides data integrity checks and protects the contents of the BLOB from third parties using provides data integrity checks and protects the contents of the BLOB from third parties using
network and application level encryption. network and application level encryption.
@ -68,7 +68,7 @@ Chunks
------ ------
Each block is divided into chunks. A chunk is the smallest data unit in the BLOB transfer, and must Each block is divided into chunks. A chunk is the smallest data unit in the BLOB transfer, and must
fit inside a single Bluetooth mesh access message excluding the opcode (379 bytes or less). The fit inside a single Bluetooth Mesh access message excluding the opcode (379 bytes or less). The
mechanism for transferring chunks depends on the transfer mode. mechanism for transferring chunks depends on the transfer mode.
When operating in Push BLOB Transfer Mode, the chunks are sent as unacknowledged packets from the When operating in Push BLOB Transfer Mode, the chunks are sent as unacknowledged packets from the

2
doc/connectivity/bluetooth/api/mesh/blob_cli.rst
View file

@ -67,7 +67,7 @@ Target nodes having the BLOB Transfer Server model subscribe to this group addre
Using group addresses for transferring the BLOBs can generally increase the transfer speed, as the Using group addresses for transferring the BLOBs can generally increase the transfer speed, as the
BLOB Transfer Client sends each message to all Target nodes at the same time. However, sending BLOB Transfer Client sends each message to all Target nodes at the same time. However, sending
large, segmented messages to group addresses in Bluetooth mesh is generally less reliable than large, segmented messages to group addresses in Bluetooth Mesh is generally less reliable than
sending them to unicast addresses, as there is no transport layer acknowledgment mechanism for sending them to unicast addresses, as there is no transport layer acknowledgment mechanism for
groups. This can lead to longer recovery periods at the end of each block, and increases the risk of groups. This can lead to longer recovery periods at the end of each block, and increases the risk of
losing Target nodes. Using group addresses for BLOB transfers will generally only pay off if the losing Target nodes. Using group addresses for BLOB transfers will generally only pay off if the

2
doc/connectivity/bluetooth/api/mesh/blob_srv.rst
View file

@ -77,7 +77,7 @@ Transfer recovery
***************** *****************
The state of the BLOB transfer is stored persistently. If a reboot occurs, the BLOB Transfer Server The state of the BLOB transfer is stored persistently. If a reboot occurs, the BLOB Transfer Server
will attempt to recover the transfer. When the Bluetooth mesh subsystem is started (for instance by will attempt to recover the transfer. When the Bluetooth Mesh subsystem is started (for instance by
calling :c:func:`bt_mesh_init`), the BLOB Transfer Server will check for aborted transfers, and call calling :c:func:`bt_mesh_init`), the BLOB Transfer Server will check for aborted transfers, and call
the :c:member:`recover <bt_mesh_blob_srv_cb.recover>` callback if there is any. In the recover the :c:member:`recover <bt_mesh_blob_srv_cb.recover>` callback if there is any. In the recover
callback, the user must provide a BLOB stream to use for the rest of the transfer. If the recover callback, the user must provide a BLOB stream to use for the rest of the transfer. If the recover

2
doc/connectivity/bluetooth/api/mesh/cfg.rst
View file

@ -6,7 +6,7 @@ Runtime Configuration
The runtime configuration API allows applications to change their runtime The runtime configuration API allows applications to change their runtime
configuration directly, without going through the Configuration models. configuration directly, without going through the Configuration models.
Bluetooth mesh nodes should generally be configured by a central network Bluetooth Mesh nodes should generally be configured by a central network
configurator device with a :ref:`bluetooth_mesh_models_cfg_cli` model. Each configurator device with a :ref:`bluetooth_mesh_models_cfg_cli` model. Each
mesh node instantiates a :ref:`bluetooth_mesh_models_cfg_srv` model that the mesh node instantiates a :ref:`bluetooth_mesh_models_cfg_srv` model that the
Configuration Client can communicate with to change the node configuration. In some Configuration Client can communicate with to change the node configuration. In some

2
doc/connectivity/bluetooth/api/mesh/cfg_cli.rst
View file

@ -3,7 +3,7 @@
Configuration Client Configuration Client
#################### ####################
The Configuration Client model is a foundation model defined by the Bluetooth mesh The Configuration Client model is a foundation model defined by the Bluetooth Mesh
specification. It provides functionality for configuring most parameters of a specification. It provides functionality for configuring most parameters of a
mesh node, including encryption keys, model configuration and feature mesh node, including encryption keys, model configuration and feature
enabling. enabling.

4
doc/connectivity/bluetooth/api/mesh/cfg_srv.rst
View file

@ -3,7 +3,7 @@
Configuration Server Configuration Server
#################### ####################
The Configuration Server model is a foundation model defined by the Bluetooth mesh The Configuration Server model is a foundation model defined by the Bluetooth Mesh
specification. The Configuration Server model controls most parameters of the specification. The Configuration Server model controls most parameters of the
mesh node. It does not have an API of its own, but relies on a mesh node. It does not have an API of its own, but relies on a
:ref:`bluetooth_mesh_models_cfg_cli` to control it. :ref:`bluetooth_mesh_models_cfg_cli` to control it.
@ -14,7 +14,7 @@ mesh node. It does not have an API of its own, but relies on a
should be set through Kconfig, and the Heartbeat feature should be should be set through Kconfig, and the Heartbeat feature should be
controlled through the :ref:`bluetooth_mesh_heartbeat` API. controlled through the :ref:`bluetooth_mesh_heartbeat` API.
The Configuration Server model is mandatory on all Bluetooth mesh nodes, and The Configuration Server model is mandatory on all Bluetooth Mesh nodes, and
must only be instantiated on the primary element. must only be instantiated on the primary element.
API reference API reference

4
doc/connectivity/bluetooth/api/mesh/core.rst
View file

@ -3,7 +3,7 @@
Core Core
#### ####
The core provides functionality for managing the general Bluetooth mesh The core provides functionality for managing the general Bluetooth Mesh
state. state.
.. _bluetooth_mesh_lpn: .. _bluetooth_mesh_lpn:
@ -117,7 +117,7 @@ Advertisement identity
All mesh stack bearers advertise data with the :c:macro:`BT_ID_DEFAULT` local identity. All mesh stack bearers advertise data with the :c:macro:`BT_ID_DEFAULT` local identity.
The value is preset in the mesh stack implementation. When Bluetooth® Low Energy (LE) The value is preset in the mesh stack implementation. When Bluetooth® Low Energy (LE)
and Bluetooth mesh coexist on the same device, the application should allocate and and Bluetooth Mesh coexist on the same device, the application should allocate and
configure another local identity for Bluetooth LE purposes before starting the communication. configure another local identity for Bluetooth LE purposes before starting the communication.
API reference API reference

24
doc/connectivity/bluetooth/api/mesh/dfu.rst
View file

@ -3,16 +3,16 @@
Device Firmware Update (DFU) Device Firmware Update (DFU)
############################ ############################
Bluetooth mesh supports the distribution of firmware images across a mesh network. The Bluetooth Bluetooth Mesh supports the distribution of firmware images across a mesh network. The Bluetooth
mesh DFU subsystem implements the Bluetooth Mesh Device Firmware Update Model specification version mesh DFU subsystem implements the Bluetooth Mesh Device Firmware Update Model specification version
1.0. The implementation is in experimental state. 1.0. The implementation is in experimental state.
Bluetooth mesh DFU implements a distribution mechanism for firmware images, and does not put any Bluetooth Mesh DFU implements a distribution mechanism for firmware images, and does not put any
restrictions on the size, format or usage of the images. The primary design goal of the subsystem is restrictions on the size, format or usage of the images. The primary design goal of the subsystem is
to provide the qualifiable parts of the Bluetooth mesh DFU specification, and leave the usage, to provide the qualifiable parts of the Bluetooth Mesh DFU specification, and leave the usage,
firmware validation and deployment to the application. firmware validation and deployment to the application.
The DFU specification is implemented in the Zephyr Bluetooth mesh DFU subsystem as three separate The DFU specification is implemented in the Zephyr Bluetooth Mesh DFU subsystem as three separate
models: models:
.. toctree:: .. toctree::
@ -28,7 +28,7 @@ Overview
DFU roles DFU roles
========= =========
The Bluetooth mesh DFU subsystem defines three different roles the mesh nodes have to assume in the The Bluetooth Mesh DFU subsystem defines three different roles the mesh nodes have to assume in the
distribution of firmware images: distribution of firmware images:
Target node Target node
@ -47,20 +47,20 @@ Distributor
image to the Target nodes. image to the Target nodes.
Initiator Initiator
The Initiator role is typically implemented by the same device that implements the Bluetooth mesh The Initiator role is typically implemented by the same device that implements the Bluetooth Mesh
:ref:`Provisioner <bluetooth_mesh_provisioning>` and :ref:`Configurator :ref:`Provisioner <bluetooth_mesh_provisioning>` and :ref:`Configurator
<bluetooth_mesh_models_cfg_cli>` roles. The Initiator needs a full overview of the potential <bluetooth_mesh_models_cfg_cli>` roles. The Initiator needs a full overview of the potential
Target nodes and their firmware, and will control (and initiate) all firmware updates. The Target nodes and their firmware, and will control (and initiate) all firmware updates. The
Initiator role is not implemented in the Zephyr Bluetooth mesh DFU subsystem. Initiator role is not implemented in the Zephyr Bluetooth Mesh DFU subsystem.
.. figure:: images/dfu_roles_mesh.svg .. figure:: images/dfu_roles_mesh.svg
:align: center :align: center
:alt: Graphic overview of the DFU roles mesh nodes can have during the process of image :alt: Graphic overview of the DFU roles mesh nodes can have during the process of image
distribution distribution
DFU roles and the associated Bluetooth mesh models DFU roles and the associated Bluetooth Mesh models
Bluetooth mesh applications may combine the DFU roles in any way they'd like, and even take on Bluetooth Mesh applications may combine the DFU roles in any way they'd like, and even take on
multiple instances of the same role by instantiating the models on separate elements. For instance, multiple instances of the same role by instantiating the models on separate elements. For instance,
the Distributor and Initiator role can be combined by instantiating the the Distributor and Initiator role can be combined by instantiating the
:ref:`bluetooth_mesh_dfu_cli` on the Initiator node and calling its API directly. :ref:`bluetooth_mesh_dfu_cli` on the Initiator node and calling its API directly.
@ -76,7 +76,7 @@ Firmware Update Client model directly, e.g. over a serial protocol.
Stages Stages
====== ======
The Bluetooth mesh DFU process is designed to act in three stages: The Bluetooth Mesh DFU process is designed to act in three stages:
Upload stage Upload stage
First, the image is uploaded to a Distributor in a mesh network by an external entity, such as a First, the image is uploaded to a Distributor in a mesh network by an external entity, such as a
@ -131,7 +131,7 @@ Firmware metadata
Target node. The firmware metadata is optional, and its maximum length is determined by Target node. The firmware metadata is optional, and its maximum length is determined by
:kconfig:option:`CONFIG_BT_MESH_DFU_METADATA_MAXLEN`. :kconfig:option:`CONFIG_BT_MESH_DFU_METADATA_MAXLEN`.
The Bluetooth mesh DFU subsystem in Zephyr provides its own metadata format The Bluetooth Mesh DFU subsystem in Zephyr provides its own metadata format
(:c:struct:`bt_mesh_dfu_metadata`) together with a set of related functions that can be used by (:c:struct:`bt_mesh_dfu_metadata`) together with a set of related functions that can be used by
an end product. The support for it is enabled using the an end product. The support for it is enabled using the
:kconfig:option:`CONFIG_BT_MESH_DFU_METADATA` option. The format of the metadata is presented in :kconfig:option:`CONFIG_BT_MESH_DFU_METADATA` option. The format of the metadata is presented in
@ -299,7 +299,7 @@ following steps:
node firmware image index and the firmware image metadata. Each Target node performs a metadata node firmware image index and the firmware image metadata. Each Target node performs a metadata
check and prepares their BLOB Transfer Server model for the transfer, before sending a status check and prepares their BLOB Transfer Server model for the transfer, before sending a status
response to the Firmware Update Client, indicating if the firmware update will have any effect on response to the Firmware Update Client, indicating if the firmware update will have any effect on
the Bluetooth mesh state of the node. the Bluetooth Mesh state of the node.
#. The Distributor's BLOB Transfer Client model transfers the firmware image to all Target nodes. #. The Distributor's BLOB Transfer Client model transfers the firmware image to all Target nodes.
#. Once the BLOB transfer has been received, the Target nodes' applications verify that the firmware #. Once the BLOB transfer has been received, the Target nodes' applications verify that the firmware
is valid by performing checks such as signature verification or image checksums against the image is valid by performing checks such as signature verification or image checksums against the image

8
doc/connectivity/bluetooth/api/mesh/dfu_srv.rst
View file

@ -16,7 +16,7 @@ Firmware images
The Firmware Update Server holds a list of all the updatable firmware images on the device. The full The Firmware Update Server holds a list of all the updatable firmware images on the device. The full
list shall be passed to the server through the ``_imgs`` parameter in list shall be passed to the server through the ``_imgs`` parameter in
:c:macro:`BT_MESH_DFU_SRV_INIT`, and must be populated before the Bluetooth mesh subsystem is :c:macro:`BT_MESH_DFU_SRV_INIT`, and must be populated before the Bluetooth Mesh subsystem is
started. Each firmware image in the image list must be independently updatable, and should have its started. Each firmware image in the image list must be independently updatable, and should have its
own firmware ID. own firmware ID.
@ -33,9 +33,9 @@ application is described below:
.. figure:: images/dfu_srv.svg .. figure:: images/dfu_srv.svg
:align: center :align: center
:alt: Bluetooth mesh Firmware Update Server transfer :alt: Bluetooth Mesh Firmware Update Server transfer
Bluetooth mesh Firmware Update Server transfer Bluetooth Mesh Firmware Update Server transfer
Transfer check Transfer check
============== ==============
@ -118,7 +118,7 @@ updated image.
When the transfer applies to the mesh application itself, the device might have to reboot as part of When the transfer applies to the mesh application itself, the device might have to reboot as part of
the swap. This restart can be performed from inside the apply callback, or done asynchronously. the swap. This restart can be performed from inside the apply callback, or done asynchronously.
After booting up with the new firmware, the firmware image table should be updated before the After booting up with the new firmware, the firmware image table should be updated before the
Bluetooth mesh subsystem is started. Bluetooth Mesh subsystem is started.
The Distributor will read out the firmware image table to confirm that the transfer was successfully The Distributor will read out the firmware image table to confirm that the transfer was successfully
applied. If the metadata check indicated that the device would become unprovisioned, the Target node applied. If the metadata check indicated that the device would become unprovisioned, the Target node

4
doc/connectivity/bluetooth/api/mesh/health_srv.rst
View file

@ -21,7 +21,7 @@ necessarily damaging to the device. Errors indicate conditions that are
outside of the node's design limits, and may have caused invalid behavior or outside of the node's design limits, and may have caused invalid behavior or
permanent damage to the device. permanent damage to the device.
Fault values ``0x01`` to ``0x7f`` are reserved for the Bluetooth mesh Fault values ``0x01`` to ``0x7f`` are reserved for the Bluetooth Mesh
specification, and the full list of specification defined faults are available specification, and the full list of specification defined faults are available
in :ref:`bluetooth_mesh_health_faults`. Fault values ``0x80`` to ``0xff`` are in :ref:`bluetooth_mesh_health_faults`. Fault values ``0x80`` to ``0xff`` are
vendor specific. The list of faults are always reported with a company ID to vendor specific. The list of faults are always reported with a company ID to
@ -57,6 +57,6 @@ API reference
Health faults Health faults
============= =============
Fault values defined by the Bluetooth mesh specification. Fault values defined by the Bluetooth Mesh specification.
.. doxygengroup:: bt_mesh_health_faults .. doxygengroup:: bt_mesh_health_faults

2
doc/connectivity/bluetooth/api/mesh/heartbeat.rst
View file

@ -3,7 +3,7 @@
Heartbeat Heartbeat
######### #########
The Heartbeat feature provides functionality for monitoring Bluetooth mesh nodes The Heartbeat feature provides functionality for monitoring Bluetooth Mesh nodes
and determining the distance between nodes. and determining the distance between nodes.
The Heartbeat feature is configured through the :ref:`bluetooth_mesh_models_cfg_srv` model. The Heartbeat feature is configured through the :ref:`bluetooth_mesh_models_cfg_srv` model.

2
doc/connectivity/bluetooth/api/mesh/lcd_cli.rst
View file

@ -3,7 +3,7 @@
Large Composition Data Client Large Composition Data Client
############################# #############################
The Large Composition Data Client model is a foundation model defined by the Bluetooth mesh The Large Composition Data Client model is a foundation model defined by the Bluetooth Mesh
specification. The model is optional, and is enabled through the specification. The model is optional, and is enabled through the
:kconfig:option:`CONFIG_BT_MESH_LARGE_COMP_DATA_CLI` option. :kconfig:option:`CONFIG_BT_MESH_LARGE_COMP_DATA_CLI` option.

2
doc/connectivity/bluetooth/api/mesh/lcd_srv.rst
View file

@ -3,7 +3,7 @@
Large Composition Data Server Large Composition Data Server
############################# #############################
The Large Composition Data Server model is a foundation model defined by the Bluetooth mesh The Large Composition Data Server model is a foundation model defined by the Bluetooth Mesh
specification. The model is optional, and is enabled through the specification. The model is optional, and is enabled through the
:kconfig:option:`CONFIG_BT_MESH_LARGE_COMP_DATA_SRV` option. :kconfig:option:`CONFIG_BT_MESH_LARGE_COMP_DATA_SRV` option.

4
doc/connectivity/bluetooth/api/mesh/models.rst
View file

@ -6,7 +6,7 @@ Mesh models
Foundation models Foundation models
***************** *****************
The Bluetooth mesh specification defines foundation models that can be The Bluetooth Mesh specification defines foundation models that can be
used by network administrators to configure and diagnose mesh nodes. used by network administrators to configure and diagnose mesh nodes.
.. toctree:: .. toctree::
@ -34,7 +34,7 @@ used by network administrators to configure and diagnose mesh nodes.
Model specification models Model specification models
************************** **************************
In addition to the foundation models defined in the Bluetooth mesh specification, the Bluetooth Mesh In addition to the foundation models defined in the Bluetooth Mesh specification, the Bluetooth Mesh
Model Specification defines several models, some of which are implemented in Zephyr: Model Specification defines several models, some of which are implemented in Zephyr:
.. toctree:: .. toctree::

2
doc/connectivity/bluetooth/api/mesh/msg.rst
View file

@ -3,7 +3,7 @@
Message Message
####### #######
The Bluetooth mesh message provides set of structures, macros and functions used The Bluetooth Mesh message provides set of structures, macros and functions used
for preparing message buffers, managing message and acknowledged message for preparing message buffers, managing message and acknowledged message
contexts. contexts.

2
doc/connectivity/bluetooth/api/mesh/od_cli.rst
View file

@ -3,7 +3,7 @@
On-Demand Private Proxy Client On-Demand Private Proxy Client
############################## ##############################
The On-Demand Private Proxy Client model is a foundation model defined by the Bluetooth mesh The On-Demand Private Proxy Client model is a foundation model defined by the Bluetooth Mesh
specification. The model is optional, and is enabled with the specification. The model is optional, and is enabled with the
:kconfig:option:`CONFIG_BT_MESH_OD_PRIV_PROXY_CLI` option. :kconfig:option:`CONFIG_BT_MESH_OD_PRIV_PROXY_CLI` option.

2
doc/connectivity/bluetooth/api/mesh/od_srv.rst
View file

@ -3,7 +3,7 @@
On-Demand Private Proxy Server On-Demand Private Proxy Server
############################## ##############################
The On-Demand Private Proxy Server model is a foundation model defined by the Bluetooth mesh The On-Demand Private Proxy Server model is a foundation model defined by the Bluetooth Mesh
specification. It is enabled with the :kconfig:option:`CONFIG_BT_MESH_OD_PRIV_PROXY_SRV` option. specification. It is enabled with the :kconfig:option:`CONFIG_BT_MESH_OD_PRIV_PROXY_SRV` option.
The On-Demand Private Proxy Server model was introduced in the Bluetooth Mesh Protocol Specification The On-Demand Private Proxy Server model was introduced in the Bluetooth Mesh Protocol Specification

2
doc/connectivity/bluetooth/api/mesh/op_agg_cli.rst
View file

@ -3,7 +3,7 @@
Opcodes Aggregator Client Opcodes Aggregator Client
######################### #########################
The Opcodes Aggregator Client model is a foundation model defined by the Bluetooth mesh The Opcodes Aggregator Client model is a foundation model defined by the Bluetooth Mesh
specification. It is an optional model, enabled with the :kconfig:option:`CONFIG_BT_MESH_OP_AGG_CLI` specification. It is an optional model, enabled with the :kconfig:option:`CONFIG_BT_MESH_OP_AGG_CLI`
option. option.

2
doc/connectivity/bluetooth/api/mesh/priv_beacon_cli.rst
View file

@ -11,7 +11,7 @@ The Private Beacon Client model is introduced in the Bluetooth Mesh Protocol
Specification version 1.1, and provides functionality for configuring the Specification version 1.1, and provides functionality for configuring the
:ref:`bluetooth_mesh_models_priv_beacon_srv` models. :ref:`bluetooth_mesh_models_priv_beacon_srv` models.
The Private Beacons feature adds privacy to the different Bluetooth mesh The Private Beacons feature adds privacy to the different Bluetooth Mesh
beacons by periodically randomizing the beacon input data. This protects the beacons by periodically randomizing the beacon input data. This protects the
mesh node from being tracked by devices outside the mesh network, and hides the mesh node from being tracked by devices outside the mesh network, and hides the
network's IV index, IV update and the Key Refresh state. network's IV index, IV update and the Key Refresh state.

2
doc/connectivity/bluetooth/api/mesh/priv_beacon_srv.rst
View file

@ -11,7 +11,7 @@ The Private Beacon Server model is introduced in the Bluetooth Mesh Protocol
Specification version 1.1, and controls the mesh node's Private Beacon state, Specification version 1.1, and controls the mesh node's Private Beacon state,
Private GATT Proxy state and Private Node Identity state. Private GATT Proxy state and Private Node Identity state.
The Private Beacons feature adds privacy to the different Bluetooth mesh The Private Beacons feature adds privacy to the different Bluetooth Mesh
beacons by periodically randomizing the beacon input data. This protects the beacons by periodically randomizing the beacon input data. This protects the
mesh node from being tracked by devices outside the mesh network, and hides the mesh node from being tracked by devices outside the mesh network, and hides the
network's IV index, IV update and the Key Refresh state. The Private Beacon Server network's IV index, IV update and the Key Refresh state. The Private Beacon Server

8
doc/connectivity/bluetooth/api/mesh/provisioning.rst
View file

@ -12,15 +12,15 @@ two devices operating in the following roles:
Provisioning process. Before the provisioning process starts, the Provisioning process. Before the provisioning process starts, the
provisionee is an *unprovisioned device*. provisionee is an *unprovisioned device*.
The Provisioning module in the Zephyr Bluetooth mesh stack supports both the The Provisioning module in the Zephyr Bluetooth Mesh stack supports both the
Advertising and GATT Provisioning bearers for the provisionee role, as well as Advertising and GATT Provisioning bearers for the provisionee role, as well as
the Advertising Provisioning bearer for the provisioner role. the Advertising Provisioning bearer for the provisioner role.
The Provisioning process The Provisioning process
************************ ************************
All Bluetooth mesh nodes must be provisioned before they can participate in a All Bluetooth Mesh nodes must be provisioned before they can participate in a
Bluetooth mesh network. The Provisioning API provides all the functionality Bluetooth Mesh network. The Provisioning API provides all the functionality
necessary for a device to become a provisioned mesh node. necessary for a device to become a provisioned mesh node.
Provisioning is a five-step process, involving the following steps: Provisioning is a five-step process, involving the following steps:
@ -176,7 +176,7 @@ Depending on the choice of public key exchange mechanism and authentication meth
the provisioning process can be secure or insecure. the provisioning process can be secure or insecure.
On May 24th 2021, ANSSI `disclosed <https://kb.cert.org/vuls/id/799380>`_ On May 24th 2021, ANSSI `disclosed <https://kb.cert.org/vuls/id/799380>`_
a set of vulnerabilities in the Bluetooth mesh provisioning protocol that showcased a set of vulnerabilities in the Bluetooth Mesh provisioning protocol that showcased
how the low entropy provided by the Blink, Vibrate, Push, Twist and how the low entropy provided by the Blink, Vibrate, Push, Twist and
Input/Output numeric OOB methods could be exploited in impersonation and MITM Input/Output numeric OOB methods could be exploited in impersonation and MITM
attacks. In response, the Bluetooth SIG has reclassified these OOB methods as attacks. In response, the Bluetooth SIG has reclassified these OOB methods as

2
doc/connectivity/bluetooth/api/mesh/proxy.rst
View file

@ -3,7 +3,7 @@
Proxy Proxy
##### #####
The Proxy feature allows legacy devices like phones to access the Bluetooth mesh network through The Proxy feature allows legacy devices like phones to access the Bluetooth Mesh network through
GATT. The Proxy feature is only compiled in if the :kconfig:option:`CONFIG_BT_MESH_GATT_PROXY` GATT. The Proxy feature is only compiled in if the :kconfig:option:`CONFIG_BT_MESH_GATT_PROXY`
option is set. The Proxy feature state is controlled by the :ref:`bluetooth_mesh_models_cfg_srv`, option is set. The Proxy feature state is controlled by the :ref:`bluetooth_mesh_models_cfg_srv`,
and the initial value can be set with :c:member:`bt_mesh_cfg_srv.gatt_proxy`. and the initial value can be set with :c:member:`bt_mesh_cfg_srv.gatt_proxy`.

4
doc/connectivity/bluetooth/api/mesh/sar_cfg.rst
View file

@ -4,7 +4,7 @@ Segmentation and reassembly (SAR)
################################# #################################
Segmentation and reassembly (SAR) provides a way of handling larger upper transport layer messages Segmentation and reassembly (SAR) provides a way of handling larger upper transport layer messages
in a mesh network, with a purpose of enhancing the Bluetooth mesh throughput. The segmentation and in a mesh network, with a purpose of enhancing the Bluetooth Mesh throughput. The segmentation and
reassembly mechanism is used by the lower transport layer. reassembly mechanism is used by the lower transport layer.
The lower transport layer defines how the upper transport layer PDUs are segmented and reassembled The lower transport layer defines how the upper transport layer PDUs are segmented and reassembled
@ -23,7 +23,7 @@ required. Set the ``send rel`` flag (see :c:struct:`bt_mesh_msg_ctx`) to use the
transmission and acknowledge single-segment segmented messages. transmission and acknowledge single-segment segmented messages.
The transport layer is able to transport up to 32 segments with its SAR mechanism, with a maximum The transport layer is able to transport up to 32 segments with its SAR mechanism, with a maximum
message (PDU) size of 384 octets. To configure message size for the Bluetooth mesh stack, use the message (PDU) size of 384 octets. To configure message size for the Bluetooth Mesh stack, use the
following Kconfig options: following Kconfig options:
* :kconfig:option:`CONFIG_BT_MESH_RX_SEG_MAX` to set the maximum number of segments in an incoming message. * :kconfig:option:`CONFIG_BT_MESH_RX_SEG_MAX` to set the maximum number of segments in an incoming message.

2
doc/connectivity/bluetooth/api/mesh/sar_cfg_cli.rst
View file

@ -3,7 +3,7 @@
SAR Configuration Client SAR Configuration Client
######################## ########################
The SAR Configuration Client model is a foundation model defined by the Bluetooth mesh The SAR Configuration Client model is a foundation model defined by the Bluetooth Mesh
specification. It is an optional model, enabled with the specification. It is an optional model, enabled with the
:kconfig:option:`CONFIG_BT_MESH_SAR_CFG_CLI` configuration option. :kconfig:option:`CONFIG_BT_MESH_SAR_CFG_CLI` configuration option.

4
doc/connectivity/bluetooth/api/mesh/sar_cfg_srv.rst
View file

@ -3,13 +3,13 @@
SAR Configuration Server SAR Configuration Server
######################## ########################
The SAR Configuration Server model is a foundation model defined by the Bluetooth mesh The SAR Configuration Server model is a foundation model defined by the Bluetooth Mesh
specification. It is an optional model, enabled with the specification. It is an optional model, enabled with the
:kconfig:option:`CONFIG_BT_MESH_SAR_CFG_SRV` configuration option. :kconfig:option:`CONFIG_BT_MESH_SAR_CFG_SRV` configuration option.
The SAR Configuration Server model is introduced in the Bluetooth Mesh Protocol Specification The SAR Configuration Server model is introduced in the Bluetooth Mesh Protocol Specification
version 1.1, and it supports the configuration of the version 1.1, and it supports the configuration of the
:ref:`segmentation and reassembly (SAR) <bluetooth_mesh_sar_cfg>` behavior of a Bluetooth mesh node. :ref:`segmentation and reassembly (SAR) <bluetooth_mesh_sar_cfg>` behavior of a Bluetooth Mesh node.
The model defines a set of states and messages for the SAR configuration. The model defines a set of states and messages for the SAR configuration.
The SAR Configuration Server model defines two states, SAR Transmitter state and SAR Receiver state. The SAR Configuration Server model defines two states, SAR Transmitter state and SAR Receiver state.

34
doc/connectivity/bluetooth/api/mesh/shell.rst
View file

@ -3,32 +3,32 @@
Bluetooth Mesh Shell Bluetooth Mesh Shell
#################### ####################
The Bluetooth mesh shell subsystem provides a set of Bluetooth mesh shell commands for the The Bluetooth Mesh shell subsystem provides a set of Bluetooth Mesh shell commands for the
:ref:`shell_api` module. It allows for testing and exploring the Bluetooth mesh API through an :ref:`shell_api` module. It allows for testing and exploring the Bluetooth Mesh API through an
interactive interface, without having to write an application. interactive interface, without having to write an application.
The Bluetooth mesh shell interface provides access to most Bluetooth mesh features, including The Bluetooth Mesh shell interface provides access to most Bluetooth Mesh features, including
provisioning, configuration, and message sending. provisioning, configuration, and message sending.
Prerequisites Prerequisites
************* *************
The Bluetooth mesh shell subsystem depends on the application to create the composition data and do The Bluetooth Mesh shell subsystem depends on the application to create the composition data and do
the mesh initialization. the mesh initialization.
Application Application
*********** ***********
The Bluetooth mesh shell subsystem is most easily used through the Bluetooth mesh shell application The Bluetooth Mesh shell subsystem is most easily used through the Bluetooth Mesh shell application
under ``tests/bluetooth/mesh_shell``. See :ref:`shell_api` for information on how to connect and under ``tests/bluetooth/mesh_shell``. See :ref:`shell_api` for information on how to connect and
interact with the Bluetooth mesh shell application. interact with the Bluetooth Mesh shell application.
Basic usage Basic usage
*********** ***********
The Bluetooth mesh shell subsystem adds a single ``mesh`` command, which holds a set of The Bluetooth Mesh shell subsystem adds a single ``mesh`` command, which holds a set of
sub-commands. Every time the device boots up, make sure to call ``mesh init`` before any of the sub-commands. Every time the device boots up, make sure to call ``mesh init`` before any of the
other Bluetooth mesh shell commands can be called:: other Bluetooth Mesh shell commands can be called::
uart:~$ mesh init uart:~$ mesh init
@ -82,7 +82,7 @@ Message sending
=============== ===============
With an application key added (see above), the mesh node's transition parameters are all valid, and With an application key added (see above), the mesh node's transition parameters are all valid, and
the Bluetooth mesh shell can send raw mesh messages through the network. the Bluetooth Mesh shell can send raw mesh messages through the network.
For example, to send a Generic OnOff Set message, call:: For example, to send a Generic OnOff Set message, call::
@ -107,7 +107,7 @@ configured network and application keys will receive and process the messages we
Sending raw mesh packets is a good way to test model message handler implementations during Sending raw mesh packets is a good way to test model message handler implementations during
development, as it can be done without having to implement the sending model. By default, only the development, as it can be done without having to implement the sending model. By default, only the
reception of the model messages can be tested this way, as the Bluetooth mesh shell only includes reception of the model messages can be tested this way, as the Bluetooth Mesh shell only includes
the foundation models. To receive a packet in the mesh node, you have to add a model with a valid the foundation models. To receive a packet in the mesh node, you have to add a model with a valid
opcode handler list to the composition data in ``subsys/bluetooth/mesh/shell.c``, and print the opcode handler list to the composition data in ``subsys/bluetooth/mesh/shell.c``, and print the
incoming message to the shell in the handler callback. incoming message to the shell in the handler callback.
@ -115,7 +115,7 @@ incoming message to the shell in the handler callback.
Parameter formats Parameter formats
***************** *****************
The Bluetooth mesh shell commands are parsed with a variety of formats: The Bluetooth Mesh shell commands are parsed with a variety of formats:
.. list-table:: Parameter formats .. list-table:: Parameter formats
:widths: 1 4 2 :widths: 1 4 2
@ -139,12 +139,12 @@ The Bluetooth mesh shell commands are parsed with a variety of formats:
Commands Commands
******** ********
The Bluetooth mesh shell implements a large set of commands. Some of the commands accept parameters, The Bluetooth Mesh shell implements a large set of commands. Some of the commands accept parameters,
which are mentioned in brackets after the command name. For example, which are mentioned in brackets after the command name. For example,
``mesh lpn set <value: off, on>``. Mandatory parameters are marked with angle brackets (e.g. ``mesh lpn set <value: off, on>``. Mandatory parameters are marked with angle brackets (e.g.
``<NetKeyIdx>``), and optional parameters are marked with square brackets (e.g. ``[DstAddr]``). ``<NetKeyIdx>``), and optional parameters are marked with square brackets (e.g. ``[DstAddr]``).
The Bluetooth mesh shell commands are divided into the following groups: The Bluetooth Mesh shell commands are divided into the following groups:
.. contents:: .. contents::
:depth: 1 :depth: 1
@ -500,10 +500,10 @@ application. This shell module can be used for configuring itself and other node
network. network.
The Configuration Client uses general message parameters set by ``mesh target dst`` and ``mesh The Configuration Client uses general message parameters set by ``mesh target dst`` and ``mesh
target net`` to target specific nodes. When the Bluetooth mesh shell node is provisioned, given that target net`` to target specific nodes. When the Bluetooth Mesh shell node is provisioned, given that
the :kconfig:option:`CONFIG_BT_MESH_SHELL_PROV_CTX_INSTANCE` option is enabled with the shell the :kconfig:option:`CONFIG_BT_MESH_SHELL_PROV_CTX_INSTANCE` option is enabled with the shell
provisioning context initialized, the Configuration Client model targets itself by default. provisioning context initialized, the Configuration Client model targets itself by default.
Similarly, when another node has been provisioned by the Bluetooth mesh shell, the Configuration Similarly, when another node has been provisioned by the Bluetooth Mesh shell, the Configuration
Client model targets the new node. In most common use-cases, the Configuration Client is depending Client model targets the new node. In most common use-cases, the Configuration Client is depending
on the provisioning features and the Configuration database to be fully functional. The on the provisioning features and the Configuration database to be fully functional. The
Configuration Client always sends messages using the Device key bound to the destination address, so Configuration Client always sends messages using the Device key bound to the destination address, so
@ -1645,7 +1645,7 @@ The Private Beacon Client model is an optional mesh subsystem that can be enable
Opcodes Aggregator Client Opcodes Aggregator Client
------------------------- -------------------------
The Opcodes Aggregator client is an optional Bluetooth mesh model that can be enabled through the The Opcodes Aggregator client is an optional Bluetooth Mesh model that can be enabled through the
:kconfig:option:`CONFIG_BT_MESH_OP_AGG_CLI` configuration option. The Opcodes Aggregator Client :kconfig:option:`CONFIG_BT_MESH_OP_AGG_CLI` configuration option. The Opcodes Aggregator Client
model is used to support the functionality of dispatching a sequence of access layer messages to model is used to support the functionality of dispatching a sequence of access layer messages to
nodes supporting the Opcodes Aggregator Server model. nodes supporting the Opcodes Aggregator Server model.
@ -1675,7 +1675,7 @@ nodes supporting the Opcodes Aggregator Server model.
Remote Provisioning Client Remote Provisioning Client
-------------------------- --------------------------
The Remote Provisioning Client is an optional Bluetooth mesh model enabled through the The Remote Provisioning Client is an optional Bluetooth Mesh model enabled through the
:kconfig:option:`CONFIG_BT_MESH_RPR_CLI` configuration option. The Remote Provisioning Client model :kconfig:option:`CONFIG_BT_MESH_RPR_CLI` configuration option. The Remote Provisioning Client model
provides support for remote provisioning of devices into a mesh network by using the Remote provides support for remote provisioning of devices into a mesh network by using the Remote
Provisioning Server model. Provisioning Server model.

2
doc/connectivity/bluetooth/bluetooth-arch.rst
View file

@ -248,7 +248,7 @@ Each role comes with its own build-time configuration option:
connection-oriented roles central implicitly enables observer role, and connection-oriented roles central implicitly enables observer role, and
peripheral implicitly enables broadcaster role. Usually the first step peripheral implicitly enables broadcaster role. Usually the first step
when creating an application is to decide which roles are needed and go when creating an application is to decide which roles are needed and go
from there. Bluetooth mesh is a slightly special case, requiring at from there. Bluetooth Mesh is a slightly special case, requiring at
least the observer and broadcaster roles, and possibly also the least the observer and broadcaster roles, and possibly also the
Peripheral role. This will be described in more detail in a later Peripheral role. This will be described in more detail in a later
section. section.

2
doc/connectivity/bluetooth/overview.rst
View file

@ -76,7 +76,7 @@ Bluetooth stack.
* Non-volatile storage support for permanent storage of Bluetooth-specific * Non-volatile storage support for permanent storage of Bluetooth-specific
settings and data settings and data
* Bluetooth mesh support * Bluetooth Mesh support
* Relay, Friend Node, Low-Power Node (LPN) and GATT Proxy features * Relay, Friend Node, Low-Power Node (LPN) and GATT Proxy features
* Both Provisioning roles and bearers supported (PB-ADV & PB-GATT) * Both Provisioning roles and bearers supported (PB-ADV & PB-GATT)

2
doc/introduction/index.rst
View file

@ -125,7 +125,7 @@ Zephyr offers a large and ever growing number of features including:
**Bluetooth Low Energy 5.0 support** **Bluetooth Low Energy 5.0 support**
Bluetooth 5.0 compliant (ESR10) and Bluetooth Low Energy Controller support Bluetooth 5.0 compliant (ESR10) and Bluetooth Low Energy Controller support
(LE Link Layer). Includes Bluetooth mesh and a Bluetooth qualification-ready (LE Link Layer). Includes Bluetooth Mesh and a Bluetooth qualification-ready
Bluetooth controller. Bluetooth controller.
* Generic Access Profile (GAP) with all possible LE roles * Generic Access Profile (GAP) with all possible LE roles

2
doc/kernel/timeutil.rst
View file

@ -223,7 +223,7 @@ include:
- GPS time: epoch of 1980-01-06T00:00:00Z, continuous following TAI with an - GPS time: epoch of 1980-01-06T00:00:00Z, continuous following TAI with an
offset of TAI-GPS=19 s. offset of TAI-GPS=19 s.
- Bluetooth mesh time: epoch of 2000-01-01T00:00:00Z, continuous following TAI - Bluetooth Mesh time: epoch of 2000-01-01T00:00:00Z, continuous following TAI
with an offset of -32. with an offset of -32.
- UNIX Leap Time: epoch of 1970-01-01T00:00:00Z, continuous following TAI with - UNIX Leap Time: epoch of 1970-01-01T00:00:00Z, continuous following TAI with
an offset of -8. an offset of -8.

4
doc/security/vulnerabilities.rst
View file

@ -1176,7 +1176,7 @@ This has been fixed in main for v3.0.0
CVE-2022-1041 CVE-2022-1041
-------------- --------------
Out-of-bound write vulnerability in the Bluetooth mesh core stack can be triggered during provisioning Out-of-bound write vulnerability in the Bluetooth Mesh core stack can be triggered during provisioning
This has been fixed in main for v3.1.0 This has been fixed in main for v3.1.0
@ -1195,7 +1195,7 @@ This has been fixed in main for v3.1.0
CVE-2022-1042 CVE-2022-1042
-------------- --------------
Out-of-bound write vulnerability in the Bluetooth mesh core stack can be triggered during provisioning Out-of-bound write vulnerability in the Bluetooth Mesh core stack can be triggered during provisioning
This has been fixed in main for v3.1.0 This has been fixed in main for v3.1.0

2
include/zephyr/bluetooth/mesh.h
View file

@ -1,5 +1,5 @@
/** @file /** @file
* @brief Bluetooth mesh Profile APIs. * @brief Bluetooth Mesh Profile APIs.
*/ */
/* /*

2
include/zephyr/bluetooth/mesh/blob_srv.h
View file

@ -108,7 +108,7 @@ struct bt_mesh_blob_srv_cb {
/** @brief Transfer recovery callback. /** @brief Transfer recovery callback.
* *
* Called when the Bluetooth mesh subsystem is started if the device is rebooted * Called when the Bluetooth Mesh subsystem is started if the device is rebooted
* in the middle of a transfer. * in the middle of a transfer.
* *
* Transfers will not be resumed after a reboot if this callback is not * Transfers will not be resumed after a reboot if this callback is not

2
include/zephyr/bluetooth/mesh/cfg.h
View file

@ -26,7 +26,7 @@
extern "C" { extern "C" {
#endif #endif
/** Bluetooth mesh feature states */ /** Bluetooth Mesh feature states */
enum bt_mesh_feat_state { enum bt_mesh_feat_state {
/** Feature is supported, but disabled. */ /** Feature is supported, but disabled. */
BT_MESH_FEATURE_DISABLED, BT_MESH_FEATURE_DISABLED,

2
include/zephyr/bluetooth/mesh/dfu_cli.h
View file

@ -9,7 +9,7 @@
* @defgroup bt_mesh_dfu_cli Firmware Uppdate Client model * @defgroup bt_mesh_dfu_cli Firmware Uppdate Client model
* @ingroup bt_mesh_dfu * @ingroup bt_mesh_dfu
* @{ * @{
* @brief API for the Bluetooth mesh Firmware Update Client model * @brief API for the Bluetooth Mesh Firmware Update Client model
*/ */
#ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_DFU_CLI_H__ #ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_DFU_CLI_H__

4
include/zephyr/bluetooth/mesh/dfu_metadata.h
View file

@ -6,10 +6,10 @@
/** /**
* @file * @file
* @defgroup bt_mesh_dfu_metadata Bluetooth mesh Device Firmware Update (DFU) metadata * @defgroup bt_mesh_dfu_metadata Bluetooth Mesh Device Firmware Update (DFU) metadata
* @ingroup bt_mesh_dfu * @ingroup bt_mesh_dfu
* @{ * @{
* @brief Common types and functions for the Bluetooth mesh DFU metadata. * @brief Common types and functions for the Bluetooth Mesh DFU metadata.
*/ */
#ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_DFU_METADATA_H__ #ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_DFU_METADATA_H__

4
include/zephyr/bluetooth/mesh/dfu_srv.h
View file

@ -9,7 +9,7 @@
* @defgroup bt_mesh_dfu_srv Firmware Update Server model * @defgroup bt_mesh_dfu_srv Firmware Update Server model
* @ingroup bt_mesh_dfu * @ingroup bt_mesh_dfu
* @{ * @{
* @brief API for the Bluetooth mesh Firmware Update Server model * @brief API for the Bluetooth Mesh Firmware Update Server model
*/ */
#ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_DFU_SRV_H__ #ifndef ZEPHYR_INCLUDE_BLUETOOTH_MESH_DFU_SRV_H__
@ -136,7 +136,7 @@ struct bt_mesh_dfu_srv_cb {
/** @brief Transfer recovery callback. /** @brief Transfer recovery callback.
* *
* If the device reboots in the middle of a transfer, the Firmware Update Server * If the device reboots in the middle of a transfer, the Firmware Update Server
* calls this function when the Bluetooth mesh subsystem is started. * calls this function when the Bluetooth Mesh subsystem is started.
* *
* This callback is optional, but transfers will not be recovered after * This callback is optional, but transfers will not be recovered after
* a reboot without it. * a reboot without it.

6
include/zephyr/bluetooth/mesh/main.h
View file

@ -1,5 +1,5 @@
/** @file /** @file
* @brief Bluetooth mesh Protocol APIs. * @brief Bluetooth Mesh Protocol APIs.
*/ */
/* /*
@ -550,8 +550,8 @@ bool bt_mesh_is_provisioned(void);
*/ */
/** /**
* @brief Bluetooth mesh * @brief Bluetooth Mesh
* @defgroup bt_mesh Bluetooth mesh * @defgroup bt_mesh Bluetooth Mesh
* @ingroup bluetooth * @ingroup bluetooth
* @{ * @{
*/ */

2
samples/bluetooth/mesh/README.rst
View file

@ -6,7 +6,7 @@ Bluetooth: Mesh
Overview Overview
******** ********
This sample demonstrates Bluetooth mesh functionality. It has several This sample demonstrates Bluetooth Mesh functionality. It has several
standard mesh models, and supports provisioning over both the standard mesh models, and supports provisioning over both the
Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT). Advertising and the GATT Provisioning Bearers (i.e. PB-ADV and PB-GATT).
The application also needs a functioning serial console, since that's The application also needs a functioning serial console, since that's

2
samples/bluetooth/mesh_demo/README.rst
View file

@ -6,7 +6,7 @@ Bluetooth: Mesh Demo
Overview Overview
******** ********
This sample is a Bluetooth mesh application intended for demonstration This sample is a Bluetooth Mesh application intended for demonstration
purposes only. The application provisions and configures itself (i.e. no purposes only. The application provisions and configures itself (i.e. no
external provisioner needed) with hard-coded network and application key external provisioner needed) with hard-coded network and application key
values. The local unicast address can be set using a NODE_ADDR build values. The local unicast address can be set using a NODE_ADDR build

2
samples/bluetooth/mesh_provisioner/README.rst
View file

@ -6,7 +6,7 @@ Bluetooth: Mesh Provisioner
Overview Overview
******** ********
This sample demonstrates how to use the Bluetooth mesh APIs related to This sample demonstrates how to use the Bluetooth Mesh APIs related to
provisioning and using the Configuration Database (CDB). It is intended provisioning and using the Configuration Database (CDB). It is intended
to be tested together with a device capable of being provisioned. For to be tested together with a device capable of being provisioned. For
example, one could use the sample in example, one could use the sample in

2
samples/boards/nrf/mesh/onoff-app/README.rst
View file

@ -6,7 +6,7 @@ Bluetooth: Mesh OnOff Model
Overview Overview
******** ********
This is a simple application demonstrating a Bluetooth mesh multi-element node. This is a simple application demonstrating a Bluetooth Mesh multi-element node.
Each element has a mesh onoff client and server Each element has a mesh onoff client and server
model which controls one of the 4 sets of buttons and LEDs . model which controls one of the 4 sets of buttons and LEDs .

2
samples/boards/nrf/mesh/onoff_level_lighting_vnd_app/README.rst
View file

@ -4,7 +4,7 @@ Bluetooth: Mesh Generic OnOff, Generic Level, Lighting & Vendor Models
###################################################################### ######################################################################
Overview Overview
******** ********
This is a application demonstrating a Bluetooth mesh node in This is a application demonstrating a Bluetooth Mesh node in
which Root element has following models which Root element has following models
- Generic OnOff Server - Generic OnOff Server

4
samples/boards/reel_board/mesh_badge/README.rst
View file

@ -6,7 +6,7 @@ Mesh Badge
Overview Overview
******** ********
This sample app for the reel board showcases Bluetooth mesh This sample app for the reel board showcases Bluetooth Mesh
The app starts off as a regular Bluetooth GATT peripheral application. The app starts off as a regular Bluetooth GATT peripheral application.
Install the "nRF Connect" app on your phone (available both for Install the "nRF Connect" app on your phone (available both for
@ -34,7 +34,7 @@ Steps to set up
you're not happy with it you can try writing something else. you're not happy with it you can try writing something else.
#. When you're happy with the text, disconnect from the board (exit the app or #. When you're happy with the text, disconnect from the board (exit the app or
go back to the device scan page) go back to the device scan page)
#. Once disconnected the board switches over to Bluetooth mesh mode, and you #. Once disconnected the board switches over to Bluetooth Mesh mode, and you
can't connect to it anymore over GATT. can't connect to it anymore over GATT.
If you configure multiple boards like this they can communicate with If you configure multiple boards like this they can communicate with

26
subsys/bluetooth/Kconfig.logging
View file

@ -469,56 +469,56 @@ config BT_MESH_DEBUG_NET
select DEPRECATED select DEPRECATED
help help
Use this option to enable Network layer debug logs for the Use this option to enable Network layer debug logs for the
Bluetooth mesh functionality. Bluetooth Mesh functionality.
config BT_MESH_DEBUG_RPL config BT_MESH_DEBUG_RPL
bool "[DEPRECATED] Replay protection list debug" bool "[DEPRECATED] Replay protection list debug"
select DEPRECATED select DEPRECATED
help help
Use this option to enable Replay protection list debug logs Use this option to enable Replay protection list debug logs
for the Bluetooth mesh functionality. for the Bluetooth Mesh functionality.
config BT_MESH_DEBUG_TRANS config BT_MESH_DEBUG_TRANS
bool "[DEPRECATED] Transport layer debug" bool "[DEPRECATED] Transport layer debug"
select DEPRECATED select DEPRECATED
help help
Use this option to enable Transport layer debug logs for the Use this option to enable Transport layer debug logs for the
Bluetooth mesh functionality. Bluetooth Mesh functionality.
config BT_MESH_DEBUG_BEACON config BT_MESH_DEBUG_BEACON
bool "[DEPRECATED] Beacon debug" bool "[DEPRECATED] Beacon debug"
select DEPRECATED select DEPRECATED
help help
Use this option to enable Beacon-related debug logs for the Use this option to enable Beacon-related debug logs for the
Bluetooth mesh functionality. Bluetooth Mesh functionality.
config BT_MESH_DEBUG_CRYPTO config BT_MESH_DEBUG_CRYPTO
bool "[DEPRECATED] Crypto debug" bool "[DEPRECATED] Crypto debug"
select DEPRECATED select DEPRECATED
help help
Use this option to enable cryptographic debug logs for the Use this option to enable cryptographic debug logs for the
Bluetooth mesh functionality. Bluetooth Mesh functionality.
config BT_MESH_DEBUG_KEYS config BT_MESH_DEBUG_KEYS
bool "[DEPRECATED] Key management debug" bool "[DEPRECATED] Key management debug"
select DEPRECATED select DEPRECATED
help help
Use this option to enable key management debug logs for the Use this option to enable key management debug logs for the
Bluetooth mesh functionality. Bluetooth Mesh functionality.
config BT_MESH_DEBUG_PROV config BT_MESH_DEBUG_PROV
bool "[DEPRECATED] Provisioning debug" bool "[DEPRECATED] Provisioning debug"
select DEPRECATED select DEPRECATED
help help
Use this option to enable Provisioning debug logs for the Use this option to enable Provisioning debug logs for the
Bluetooth mesh functionality. Bluetooth Mesh functionality.
config BT_MESH_DEBUG_PROVISIONER config BT_MESH_DEBUG_PROVISIONER
bool "[DEPRECATED] Provisioner debug" bool "[DEPRECATED] Provisioner debug"
select DEPRECATED select DEPRECATED
help help
Use this option to enable Provisioner debug logs for the Use this option to enable Provisioner debug logs for the
Bluetooth mesh functionality. Bluetooth Mesh functionality.
config BT_MESH_DEBUG_PROV_DEVICE config BT_MESH_DEBUG_PROV_DEVICE
bool "[DEPRECATED] Provisioning device debug" bool "[DEPRECATED] Provisioning device debug"
@ -532,7 +532,7 @@ config BT_MESH_DEBUG_ACCESS
select DEPRECATED select DEPRECATED
help help
Use this option to enable Access layer and device composition Use this option to enable Access layer and device composition
related debug logs for Bluetooth mesh. related debug logs for Bluetooth Mesh.
config BT_MESH_DEBUG_MODEL config BT_MESH_DEBUG_MODEL
bool "[DEPRECATED] Foundation model debug" bool "[DEPRECATED] Foundation model debug"
@ -546,21 +546,21 @@ config BT_MESH_DEBUG_ADV
select DEPRECATED select DEPRECATED
help help
Use this option to enable advertising debug logs for Use this option to enable advertising debug logs for
the Bluetooth mesh functionality. the Bluetooth Mesh functionality.
config BT_MESH_DEBUG_LOW_POWER config BT_MESH_DEBUG_LOW_POWER
bool "[DEPRECATED] Low Power debug" bool "[DEPRECATED] Low Power debug"
select DEPRECATED select DEPRECATED
help help
Use this option to enable Low Power debug logs for the Use this option to enable Low Power debug logs for the
Bluetooth mesh functionality. Bluetooth Mesh functionality.
config BT_MESH_DEBUG_FRIEND config BT_MESH_DEBUG_FRIEND
bool "[DEPRECATED] Friend debug" bool "[DEPRECATED] Friend debug"
select DEPRECATED select DEPRECATED
help help
Use this option to enable Friend debug logs for the Use this option to enable Friend debug logs for the
Bluetooth mesh functionality. Bluetooth Mesh functionality.
config BT_MESH_DEBUG_PROXY config BT_MESH_DEBUG_PROXY
bool "[DEPRECATED] Proxy debug" bool "[DEPRECATED] Proxy debug"
@ -588,7 +588,7 @@ config BT_MESH_DEBUG_CFG
select DEPRECATED select DEPRECATED
help help
Use this option to enable node configuration debug logs for the Use this option to enable node configuration debug logs for the
Bluetooth mesh functionality. Bluetooth Mesh functionality.
endmenu # [DEPRECATED] Mesh endmenu # [DEPRECATED] Mesh

2
subsys/bluetooth/common/Kconfig
View file

@ -243,7 +243,7 @@ config BT_HCI_MESH_EXT
bool "Mesh HCI Command support" bool "Mesh HCI Command support"
depends on BT_BROADCASTER && BT_OBSERVER && !BT_LL_SW_SPLIT depends on BT_BROADCASTER && BT_OBSERVER && !BT_LL_SW_SPLIT
help help
Enable support for the Bluetooth mesh HCI Commands. Enable support for the Bluetooth Mesh HCI Commands.
config BT_WAIT_NOP config BT_WAIT_NOP
bool "Wait for \"NOP\" Command Complete event during init" bool "Wait for \"NOP\" Command Complete event during init"

20
subsys/bluetooth/mesh/Kconfig
View file

@ -1,13 +1,13 @@
# Bluetooth mesh configuration options # Bluetooth Mesh configuration options
# Copyright (c) 2017 Intel Corporation # Copyright (c) 2017 Intel Corporation
# SPDX-License-Identifier: Apache-2.0 # SPDX-License-Identifier: Apache-2.0
menuconfig BT_MESH menuconfig BT_MESH
bool "Bluetooth mesh support" bool "Bluetooth Mesh support"
depends on BT_OBSERVER && BT_BROADCASTER depends on BT_OBSERVER && BT_BROADCASTER
help help
This option enables Bluetooth mesh support. The specific This option enables Bluetooth Mesh support. The specific
features that are available may depend on other features features that are available may depend on other features
that have been enabled in the stack, such as GATT support. that have been enabled in the stack, such as GATT support.
@ -598,7 +598,7 @@ config BT_MESH_ACCESS_LAYER_MSG
help help
This option allows the application to directly access This option allows the application to directly access
Bluetooth access layer messages without the need to Bluetooth access layer messages without the need to
instantiate Bluetooth mesh models. instantiate Bluetooth Mesh models.
config BT_MESH_MODEL_VND_MSG_CID_FORCE config BT_MESH_MODEL_VND_MSG_CID_FORCE
bool "Force vendor model to use the corresponding CID field message" bool "Force vendor model to use the corresponding CID field message"
@ -1049,9 +1049,9 @@ config BT_MESH_FRIEND_ADV_LATENCY
endif # BT_MESH_FRIEND endif # BT_MESH_FRIEND
menuconfig BT_MESH_V1d1 menuconfig BT_MESH_V1d1
bool "Bluetooth mesh v1.1 support" bool "Bluetooth Mesh v1.1 support"
help help
This option enables Bluetooth mesh v1.1 support. Bluetooth mesh v1.1 This option enables Bluetooth Mesh v1.1 support. Bluetooth Mesh v1.1
is backward compatible with v1.0.1. is backward compatible with v1.0.1.
config BT_MESH_ECDH_P256_CMAC_AES128_AES_CCM config BT_MESH_ECDH_P256_CMAC_AES128_AES_CCM
@ -1201,7 +1201,7 @@ config BT_MESH_DFU_METADATA
bool "Support for the default metadata format" bool "Support for the default metadata format"
help help
This option adds a set of functions that can be used to encode and decode a firmware This option adds a set of functions that can be used to encode and decode a firmware
metadata using the format defined in the Bluetooth mesh DFU subsystem. metadata using the format defined in the Bluetooth Mesh DFU subsystem.
config BT_MESH_DFU_URI_MAXLEN config BT_MESH_DFU_URI_MAXLEN
int "DFU URI max length" int "DFU URI max length"
@ -1734,16 +1734,16 @@ config BT_MESH_RPL_STORE_TIMEOUT
endif # BT_MESH_RPL_STORAGE_MODE_SETTINGS && BT_SETTINGS endif # BT_MESH_RPL_STORAGE_MODE_SETTINGS && BT_SETTINGS
config BT_MESH_SETTINGS_WORKQ config BT_MESH_SETTINGS_WORKQ
bool "Store the Bluetooth mesh settings in a separate work queue" bool "Store the Bluetooth Mesh settings in a separate work queue"
default y default y
help help
This option enables a separate cooperative thread which is used to This option enables a separate cooperative thread which is used to
store Bluetooth mesh configuration. When this option is disabled, store Bluetooth Mesh configuration. When this option is disabled,
the stack's configuration is stored in the system workqueue. This the stack's configuration is stored in the system workqueue. This
means that the system workqueue will be blocked for the time needed means that the system workqueue will be blocked for the time needed
to store the pending data. This time may significantly increase if to store the pending data. This time may significantly increase if
the flash driver does the erase operation. Enabling this option the flash driver does the erase operation. Enabling this option
allows Bluetooth mesh not to block the system workqueue, and thus allows Bluetooth Mesh not to block the system workqueue, and thus
process the incoming and outgoing messages while the flash driver process the incoming and outgoing messages while the flash driver
waits for the controller to allocate the time needed to write the waits for the controller to allocate the time needed to write the
data and/or erase the required flash pages. data and/or erase the required flash pages.

2
subsys/bluetooth/mesh/access.h
View file

@ -94,7 +94,7 @@ void bt_mesh_msg_cb_set(void (*cb)(uint32_t opcode, struct bt_mesh_msg_ctx *ctx,
* Send a mesh model layer message out into the mesh network without having instantiated * Send a mesh model layer message out into the mesh network without having instantiated
* the relevant mesh models. * the relevant mesh models.
* *
* @param ctx The Bluetooth mesh message context. * @param ctx The Bluetooth Mesh message context.
* @param buf The message payload. * @param buf The message payload.
* *
* @return 0 on success or negative error code on failure. * @return 0 on success or negative error code on failure.

2
subsys/bluetooth/mesh/settings.c
View file

@ -88,7 +88,7 @@ static int mesh_commit(void)
} }
if (!atomic_test_bit(bt_dev.flags, BT_DEV_ENABLE)) { if (!atomic_test_bit(bt_dev.flags, BT_DEV_ENABLE)) {
/* The Bluetooth mesh settings loader calls bt_mesh_start() immediately /* The Bluetooth Mesh settings loader calls bt_mesh_start() immediately
* after loading the settings. This is not intended to work before * after loading the settings. This is not intended to work before
* bt_enable(). The doc on @ref bt_enable requires the "bt/" settings * bt_enable(). The doc on @ref bt_enable requires the "bt/" settings
* tree to be loaded after @ref bt_enable is completed, so this handler * tree to be loaded after @ref bt_enable is completed, so this handler

10
subsys/bluetooth/mesh/shell/Kconfig
View file

@ -1,13 +1,13 @@
# Bluetooth mesh shell configuration options # Bluetooth Mesh shell configuration options
# Copyright (c) 2022 Nordic Semiconductor # Copyright (c) 2022 Nordic Semiconductor
# SPDX-License-Identifier: Apache-2.0 # SPDX-License-Identifier: Apache-2.0
menuconfig BT_MESH_SHELL menuconfig BT_MESH_SHELL
bool "Bluetooth mesh shell" bool "Bluetooth Mesh shell"
select SHELL select SHELL
help help
Activate shell module that provides Bluetooth mesh commands to Activate shell module that provides Bluetooth Mesh commands to
the console. the console.
if BT_MESH_SHELL if BT_MESH_SHELL
@ -24,7 +24,7 @@ config BT_MESH_SHELL_PROV_CTX_INSTANCE
depends on BT_MESH_SHELL_PROV depends on BT_MESH_SHELL_PROV
help help
This option enables the provisioning context instance in the This option enables the provisioning context instance in the
Bluetooth mesh shell module together with several provisioning Bluetooth Mesh shell module together with several provisioning
commands and target utility features. To use the provisioning commands and target utility features. To use the provisioning
context instance, use bt_mesh_shell_prov in the context instance, use bt_mesh_shell_prov in the
initialization of mesh. initialization of mesh.
@ -54,7 +54,7 @@ config BT_MESH_SHELL_HEALTH_SRV_INSTANCE
depends on BT_MESH_SHELL_TEST depends on BT_MESH_SHELL_TEST
help help
This option enables Health Server model instance in the This option enables Health Server model instance in the
Bluetooth mesh shell module together with fault controlling Bluetooth Mesh shell module together with fault controlling
shell commands. To use the model instance, add bt_mesh_shell_health_srv shell commands. To use the model instance, add bt_mesh_shell_health_srv
to the device composition data. Use BT_MESH_SHELL_HEALTH_PUB_DEFINE to to the device composition data. Use BT_MESH_SHELL_HEALTH_PUB_DEFINE to
instantiate publication context. instantiate publication context.

2
subsys/bluetooth/mesh/shell/shell.c
View file

@ -1814,5 +1814,5 @@ SHELL_STATIC_SUBCMD_SET_CREATE(mesh_cmds,
SHELL_SUBCMD_SET_END SHELL_SUBCMD_SET_END
); );
SHELL_CMD_ARG_REGISTER(mesh, &mesh_cmds, "Bluetooth mesh shell commands", SHELL_CMD_ARG_REGISTER(mesh, &mesh_cmds, "Bluetooth Mesh shell commands",
bt_mesh_shell_mdl_cmds_help, 1, 1); bt_mesh_shell_mdl_cmds_help, 1, 1);

14
tests/bsim/bluetooth/mesh/README.rst
View file

@ -1,7 +1,7 @@
Bluetooth mesh BabbleSim tests Bluetooth Mesh BabbleSim tests
############################## ##############################
This directory contains a set of high level system tests for the Bluetooth mesh This directory contains a set of high level system tests for the Bluetooth Mesh
subsystem. The tests run on the BabbleSim simulator, using the BabbleSim test subsystem. The tests run on the BabbleSim simulator, using the BabbleSim test
framework. framework.
@ -10,7 +10,7 @@ subfolder of test_scripts contains tests for a specific module in the Bluetooth
mesh subsystem, and each folder has a corresponding test_<subfolder>.c under the mesh subsystem, and each folder has a corresponding test_<subfolder>.c under the
src/ directory containing the necessary test harnesses to execute the tests. src/ directory containing the necessary test harnesses to execute the tests.
There's only a single test application for all the Bluetooth mesh BabbleSim There's only a single test application for all the Bluetooth Mesh BabbleSim
tests. The test application is built from this directory, and includes all test tests. The test application is built from this directory, and includes all test
harnesses in every build. The overlying bsim test framework selects the harness harnesses in every build. The overlying bsim test framework selects the harness
to use at runtime, using the test identifiers passed in the test scripts. to use at runtime, using the test identifiers passed in the test scripts.
@ -18,7 +18,7 @@ to use at runtime, using the test identifiers passed in the test scripts.
Running the tests Running the tests
***************** *****************
The Bluetooth mesh tests have no extra requirements, and can be run using the The Bluetooth Mesh tests have no extra requirements, and can be run using the
procedure described in the parent folder. procedure described in the parent folder.
To only run the mesh tests, set ``SEARCH_PATH`` to point to this folder before To only run the mesh tests, set ``SEARCH_PATH`` to point to this folder before
@ -57,13 +57,13 @@ Then separately, call
Framework Framework
********* *********
The Bluetooth mesh BabbleSim tests mainly operate on the test framework for the The Bluetooth Mesh BabbleSim tests mainly operate on the test framework for the
BabbleSim platform, but with some mesh specific additions: BabbleSim platform, but with some mesh specific additions:
mesh_test.sh mesh_test.sh
============= =============
All test scripts in the Bluetooth mesh BabbleSim test suite follow a common All test scripts in the Bluetooth Mesh BabbleSim test suite follow a common
pattern for running a single test across N devices with different test pattern for running a single test across N devices with different test
harnesses. ``mesh_test.sh`` is sourced in each test script, and its ``RunTest`` harnesses. ``mesh_test.sh`` is sourced in each test script, and its ``RunTest``
function is called once in each script with the following parameters: function is called once in each script with the following parameters:
@ -113,6 +113,6 @@ has been called - otherwise, it will fail.
The Bluetooth stack must be initialized in the ``test_main_f`` function of The Bluetooth stack must be initialized in the ``test_main_f`` function of
the harness, as the previous callbacks are all executed in hardware threads. the harness, as the previous callbacks are all executed in hardware threads.
The Bluetooth mesh tests include the entire Bluetooth host and controller The Bluetooth Mesh tests include the entire Bluetooth host and controller
subsystems, so timing requirements should generally be kept fairly liberal to subsystems, so timing requirements should generally be kept fairly liberal to
avoid regressions on changes in the underlying layers. avoid regressions on changes in the underlying layers.

2
tests/bsim/bluetooth/mesh/prj.conf
View file

@ -15,7 +15,7 @@ CONFIG_BT_BROADCASTER=y
CONFIG_BT_CTLR_DUP_FILTER_LEN=0 CONFIG_BT_CTLR_DUP_FILTER_LEN=0
CONFIG_BT_CTLR_PRIVACY=n CONFIG_BT_CTLR_PRIVACY=n
# Bluetooth mesh configuration # Bluetooth Mesh configuration
CONFIG_BT_MESH=y CONFIG_BT_MESH=y
CONFIG_BT_MESH_LOG_LEVEL_DBG=y CONFIG_BT_MESH_LOG_LEVEL_DBG=y
CONFIG_BT_MESH_RELAY=y CONFIG_BT_MESH_RELAY=y

2
tests/bsim/bluetooth/mesh/prj_mesh1d1.conf
View file

@ -15,7 +15,7 @@ CONFIG_BT_BROADCASTER=y
CONFIG_BT_CTLR_DUP_FILTER_LEN=0 CONFIG_BT_CTLR_DUP_FILTER_LEN=0
CONFIG_BT_CTLR_PRIVACY=n CONFIG_BT_CTLR_PRIVACY=n
# Bluetooth mesh configuration # Bluetooth Mesh configuration
CONFIG_BT_MESH=y CONFIG_BT_MESH=y
CONFIG_BT_MESH_V1d1=y CONFIG_BT_MESH_V1d1=y
CONFIG_BT_MESH_LOG_LEVEL_DBG=y CONFIG_BT_MESH_LOG_LEVEL_DBG=y

2
tests/bsim/bluetooth/mesh/src/mesh_test.h
View file

@ -1,5 +1,5 @@
/** @file /** @file
* @brief Common functionality for Bluetooth mesh BabbleSim tests. * @brief Common functionality for Bluetooth Mesh BabbleSim tests.
*/ */
/* /*