Now that support for all PSA_WANT symbols is in place, we can
enable MBEDTLS_USE_PSA_CRYPTO when MBEDTLS_PSA_CRYPTO_C is
enabled as well.
Note: this commit also moves USE_PSA_CRYPTO out of CRYPTO_C
dependency in config-tls-generic.h because TLS/DTLS/X509 modules
of MbedTLS can rely on *any* implementation of PSA crypto APIs
not only the MbedTLS one. TFM is for example an alternative
to this.
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
MBEDTLS_PSA_CRYPTO_C and MBEDTLS_USE_PSA_CRYPTO are 2 different
things and the former should not automatically enable the
latter. The reson is that the user might want the MbedTLS
PSA crypto toolbox to be built, but at the same time he/she
does not want TLS/DTLS (and other intermediate modules such
as PK, MD and Cipher) to use PSA APIs.
For this reason this commit introduces a new Kconfig option
named CONFIG_MBEDTLS_USE_PSA_CRYPTO to enable the corresponding
build symbol. By default USE_PSA_CRYPTO is disabled. It is
only explicilty enabled in tests/samples that were previously
setting CRYPTO_C (since in those cases USE_PSA was set).
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Commit adds analyzing of returned status of element rx.
If at least one element receives multicast message then
access layer will return suceess status.
If option CONFIG_BT_MESH_ACCESS_LAYER_MSG is enabled then
access layer will return success always.
Function bt_mesh_access_recv has been introduced to cover
case when real model statuses should be returned over
oppcode aggregator model despite access returns success.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
DFD Server, DFU Server, and DFU Client models are extended models
that extend other underlaying models. If BT_MESH_MODEL_EXTENSIONS
is not enabled, extension hierarchy is not initialized and this
results in issues in subscriptions and errors in representation
of hierarchy in CDP1. Since extensions are spec defined, force
selection of this option here to prevent users forgetting about it.
Signed-off-by: Omkar Kulkarni <omkar.kulkarni@nordicsemi.no>
CDP1 is mandatory to qualify a mesh device for mesh protocol v1.1.
The dependency on BT_MESH_MODEL_EXTENSIONS is removed because if a node
contains only base models (for example Generic OnOff Server), this API
will consume extra RAM bytes which won't be used.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Bluetooth Mesh Protocol 1.1 is backward compatible with Bluetooth Mesh
Profile 1.0.1, therefore the stack can still be qualified for 1.0.1 if
needed. But explicit support for both versions requires additional
maintenance efforts and doubles the CI time. To make the stack
qualifiable for 1.0.1, the one needs to remove Private Beacons reception
and compile out SHA256 algorithm support.
What is changed:
- Removed `CONFIG_BT_MESH_V1d1` option.
- Removed `transport_legacy.c` which was using 1.0.1 implementation. The
new transport layer has new SaR logic that should still be possible to
qualify for 1.0.1.
- Removed the legacy transport Kconfig options. They are superseded by
the new transport Kconfig options.
- Tester app: `overlay-mesh-v1d1.conf` is merged into
`overlay-mesh.conf`.
- Removed BabbleSim tests for 1.0.1.
- Updated documentation.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Enable by default the access layer responses random delays.
Commit also adapts all mesh models, samples and
babblesim tests to use random delay functionality correctly.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
The section 3.7.3.1 of the mesh specification recommends to delay
a message publication in certain cases:
- at power-up or upon state change for a time between 20 to 500 ms
- for periodic publications for a time between 20 to 50 ms
This change implements this recommendation by adding the
`CONFIG_BT_MESH_DELAYABLE_PUBLICATION` Kconfig option which enables
the randomization code and by adding the `bt_mesh_model_pub.delayable`
bit field which allows each model decide whether the publications
should be delayed for this model or not.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Renames "prov device" references and options to
"provisionee" to align implementation with Mesh
Protocol specification v1.1, section 5.4.
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
Commit adds implementation of the specification
recommendations regarding randomization of
responses on the access layer.
3.7.3.1 Transmitting an Access messages
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
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>
The ability to send the solicitation PDU doesn't
depend on GATT Client role.
Commit makes independent one functionality from
another.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
If instantiated models don't have any relations at all, then the
extensions list will be empty. We should allow to disable it at all
to not waste RAM.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Since the default process dhkey gen in bt rx, will block send
Trans Ack, cause peer device send more package.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Since notice that simultaneous advertising is not only used
by relay message, provision over pb-adv can also be used.
so it was changed to a more general name.
refs:https://github.com/zephyrproject-rtos/zephyr/pull/48903
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
If RPR server is used then Mesh settings work queue
requires more size during provisioning procedure.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
This adds support for the Upload OOB Start message to the DFD server, by
providing callbacks that the application can use to hook any OOB scheme
into the model behavior.
There are also extensive changes to the dfu_slot module, to accomodate
the new needs that appeared with the support for OOB transfer (mainly,
fwid, size and metadata are no longer available when the slot is
allocated, they appear later in the handling).
Signed-off-by: Ludvig Samuelsen Jordet <ludvig.jordet@nordicsemi.no>
Adds support for composition data page 2 & 130.
In this implementation the responsibillity for filling the page 2
buffer is left to the application through the new comp page 2 cb API.
Only the application can know/decide if the device is NLC compliant,
and must thus be given the responsibillity for cheking the NLC profile
requirements, defined in the NLC specs, and filling the response buffer
for comp data page 2.
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
Updated SAR default values to align with the latest mesh 1.1 drafts,
and relevant Bsim tests.
Signed-off-by: Stine Åkredalen <stine.akredalen@nordicsemi.no>
Current structure of Bluetooth Mesh Kconfig options is quite messy.
This makes impossible to understand which configuration belongs to
which feature. Especially when using interactive Kconfig interface, like
menuconfig or guiconfig.
This commit restructures the options grouping them by protocol layer
they belong to (Network, Transport, Access, etc.), or specific feature
(LPN, Friend, Proxy, Relay, etc.), or implementation (Advertiser, Shell,
Persistent storage). Amount of supported keys, subnets, group addresses
and labels are grouped under Capabilities menu. Generic options that
don't fall to any category are kept at the root menu. For better
visibility, if a specific feature or layer has more than 1 option, they
are hidden under menu.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
PR adds the statistic module to estimate frame handling.
The module helps to understand the ratio of
the received\relayed\dropped\transmited frames.
That shows the efficiency of the current configuration\implementation.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
This PR adds ability to build mesh with tf-m psa
for platforms those support tf-m.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
After adding support for virtual addresses with collision (where two
Label UUIDs have the same virtual address), the format of the data in
the persistent storage with the Label UUIDs which a model is subscribed
to or publishes to has been changed. The recovery code is added and the
Label UUIDs will be recovered by picking first Label UUID matching to
the virtual address in the subscription list or model publication. This
options can disable the recovery code and save some flash if the
recovery is not required (e.g. virtual address support wasn't enabled
before this option was added, or the devices were unprovisioned before
upgrading to the version with this option).
Making this option as deprecated to be able to drop support of this
option and remove the recovery code eventually.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
A mesh key type has been added to be able to choose the different
key representation for different security libraries.
The type as well as some functionality related to Mesh key
management has been added as a public API.
If tynicrypt is chosen then keys have representation
as 16 bytes array. If mbedTLS with PSA is used then keys are
the PSA key id. Raw value is not kept within BLE Mesh stack
for mbedTLS. Keys are imported into the security library
and key ids are gotten back. This refactoring has been done
for the network(including all derivated keys), application,
device, and session keys.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
Currently mesh settings are stored in the system workqueue context.
Most of other stack functionality, such that advertisements (incl
relay), loopback, transport sar, beacons transmission, etc. is also
processed in the system workqueue context. When a massive amount of
data needs to be stored and in particularly when page erase needs to
be triggered by GC of NVS subsystem to allocate flash pages, the
execution of the stack (and other functionality that uses the system
workqueue) will be blocked until storing is finished. For example,
right after the provisioning of a erased device, a node may not be
responsive for up to 400ms before it can continue sending messages.
The waiting time may increase if there is a GATT connection in the
mean time.
When write or erase operation is triggered, the flash driver waits for
Bluetooth controller to allocate a time needed to perform the operation.
During the whole operation, the context from which the operation was
triggered is put to sleep. This allows other threads to run until
Bluetooth controller finds the time for the flash driver. In other words,
every settings_save_one or settings_delete should be considered as
rescheduling points.
Considering this, Bluetooth mesh can use another thread to store its
settings, thus releasing the system workqueue for other tasks including
the operation of the stack itself.
The consistency of the data to be stored is guaranteed by the current
implementation where the data is copied to another struct before calling
settings_save_one. The pending flag of a particular module is dropped in
settings.c before starting to store the corresponding data. Thus, if
during the sleep the node receives a message that triggers a change in a
module which data is currently being stored, the pending flag will be
restored and the new change will be stored eventually.
Having this option enabled including with the partial erase, will make
the node more responsive in the described situations.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Commit adds experimental support mbedtls psa as crypto
backend for ble mesh. It were run only on bsim tests.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
Commit gets rid of host dependency to generate DH key.
Mesh uses its own function for it that has synchronous
behavior and correct endianism. It simplifies the provisioning
state machine since it doesn't require waiting for the host HCI
handler.
Also, it removes hidden cross-dependency between BLE Mesh and
SMP in the aspect of competition for the same DH key
(https://github.com/zephyrproject-rtos/zephyr/issues/23292)
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
Move all Kconfig symbols related to Bluetooth logging into the newly
created `Kconfig.logging`. The logging symbols are now grouped by into a
menu "Bluetooth logging". Closely related symbols are grouped with each
others. For example, audio related logging symbol are found behind a
submenu "Audio" inside the "Bluetooth logging".
The deprecated logging symbols have also been moved in a submenu of
"Bluetooth logging", it's easier to avoid them so.
Behavior of the Bluetooth logging system:
When `LOG` symbol is selected, if Bluetooth is enabled (`BT` symbol
selected), the Bluetooth logging is enabled.
If the user does not set any log level, the Bluetooth logging symbols
will inherit the log level of `BT_LOG_LEVEL`. If the user does not set
the level of `BT_LOG_LEVEL`, the default log level will be the one
defined by the logging subsystem. Which currently is `LOG_LEVEL_INF`.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
This fixes compilation errors of BabbleSim tests generated by gcc-12
when MOD_REL_LIST_SIZE is zero.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This is initial implementation of Proxy solicitation procedure.
This includes:
- support for sending and receiving Solicitation PDUs
- On-Demand Private Proxy functionality (Server and Client) controlling
behaviour of node after receiving Solicitation PDU
- Solicitation PDU RPL Configuration (Server and Client), which manages
Replay Protection List for Solicitation PDUs.
Proxy Solicitation allows to enable advertising of Proxy service on node
by sending Solicitation PDUs. These PDUs are not part of Mesh messages;
instead, these are non-connectable, undirected advertising PDUs with
their own format, containing Proxy Solicitation UUID.
Signed-off-by: Krzysztof Kopyściński <krzysztof.kopyscinski@codecoup.pl>
This patch adds for handling Models Metadata Get Page 128.
Signed-off-by: Michal Narajowski <michal.narajowski@codecoup.pl>
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Composition Data Page 1 contains information about relations between
models. Implementation saves relations into array of tuples
{ptr to base, ptr to extension, relation type} on model initialization
and uses this information to construct Composition Data Page 1.
Appropriate structures and methods were added to API, allowing user to
parse all received data into Composition Data Page 1 formats:
Composition Data Page 1 Element, Model Item, Model Extension Item.
Signed-off-by: Krzysztof Kopyściński <krzysztof.kopyscinski@codecoup.pl>
