Previously, PB-GATT unprovisioned advs would continue being sent if a
device is provisioned or in the process of being provisioned (an active
provisioning link) over PB-ADV.
This commit introduces the `link_cancel` callback for the `prov_bearer`
struct. When a provisioning link is established over a prov bearer, all
other (active) prov bearers will be suspended through this callback, and
re-enabled when the link is closed. An exception is made for PB-REMOTE,
which can utilize the other bearers.
The call to `bt_mesh_pb_gatt_srv_disable` in settings.c is removed. This
is called in `mesh_commit`, and is not needed as this is only used
during boot, at which point the Mesh provisioning service has not yet
been enabled/registered, meaning the function does nothing.
Signed-off-by: Håvard Reierstad <haavard.reierstad@nordicsemi.no>
By using `SETTINGS_STATIC_HANDLER_DEFINE_WITH_CPRIO` we can ensure that
BT subsystems always get loaded after BT, and BT Mesh after both of
them.
This solves the host having to register a GATT service in a delayed
manner, as we are sure to now register the GATT service after sc_commit
sets `SC_LOAD`.
Signed-off-by: Kyra Lengfeld <kyra.lengfeld@nordicsemi.no>
Removed deprecated native_posix as test platform.
Added unique sim_ids for tests with the psa as a overlay.
Fixed clang-format issues.
Signed-off-by: Ingar Kulbrandstad <ingar.kulbrandstad@nordicsemi.no>
The `brg_cfg` module implements the states needed for subnet bridge
feature. It provides two states - enable state, and bridging table
state. APIs are provided to access and modify the states. The module
handles responsibility of persistence of the states.
Signed-off-by: Omkar Kulkarni <omkar.kulkarni@nordicsemi.no>
This change allows a custom RPL use pending mechanism and the mesh
settings work to store pending RPL entries. `bt_mesh_rpl_pending_store`
is a public API and should be implemented anyway. The custom RPL
implementation has to trigger settings with the
`BT_MESH_SETTINGS_RPL_PENDING` flag to ask the mesh settings work to
call `bt_mesh_rpl_pending_store`.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@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>
This commit adds the following features related to virtual addresses
support:
- Allows to store Label UUIDs which virtual addresses collide;
- Allows to decrypt messages encrypted with a virtual address with
collision;
- Allows to publish a message to a specific Label UUID to avoid virtual
addresses collision by adding a pointer to Label UUID to
struct bt_mesh_msg_ctx and struct bt_mesh_model_pub;
- Allows to differentiate Label UUIDs in the model's Subscription List
by storing all subscribed UUIDs in struct bt_mesh_model.uuids field.
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>
This allows to move flash operations from the context that triggered
storing device key candidate to the mesh settings work item that runs
on the system workqueue. This is required to for a case where the mesh
settings work item is running on a separate thread instead of the system
workqueue to unblock the system workqueue eventually.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This allows to move flash operations from the context that triggered
bt_mesh_provision or bt_mesh_reprovision to the mesh settings work item
that runs on the system workqueue. This is required to for a case where
the mesh settings work item is running on a separate thread instead of
the system workqueue to unblock the system workqueue eventually.
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>
The `bluetooth/common/log.h` and `bluetooth/common/log.c` files have been
removed. Files that were using them have been updated to use
`zephyr/logging/log.h` instead.
Those replacement have been done consequently:
- `/BT_DBG/LOG_DBG/`
- `/BT_ERR/LOG_ERR/`
- `/BT_WARN/LOG_WRN/`
- `/BT_INFO/LOG_INF/`
- `/BT_HEXDUMP_DBG/LOG_HEXDUMP_DBG/`
- `/BT_DBG_OBJ_ID/LOG_DBG_OBJ_ID/`
Also, some files were relying on the `common/log.h` include to include
`zephyr/bluetooth/hci.h`, in those cases the include of `hci.h` has
been added.
For files that were including `common/log.h` but not using any logs,
the include has been removed and not replaced.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
Replace unnecessary `BT_HEXDUMP_DBG` with `LOG_HEXDUMP_DBG`.
`BT_HEXDUMP_DBG` did an extra cast to `const uint8_t *` on its first
argument. This was probably the reason it was introduced. But the
current definition of `LOG_HEXDUMP_DBG` does this cast for us.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Upon bt_mesh_reset call, all mesh modules has to clear the privisioning
and configuration data. None of the modules store or erase in settings
subsystem immediately, but put this on the mesh settings work. After the
settings work is scheduled, all stored data will be removed and the
device will eventually be unprovisioned. Until then, the device is not
completely unprovisioned, thus calling bt_mesh_prov_enable,
bt_mesh_provision (and bt_mesh_cdb_create) should not be allowed.
Struct bt_mesh_prov has a reset callback stating that after this
callback is called, the device has been reset and can be re-provisioned
again. Also, bt_mesh_reset API description states that after calling
bt_mesh_reset API, the device needs to reenable the provisioning layer
to be provisioned again. But this is not correct since the settings has
to be cleared before the device can be reprovisionined.
This commit makes bt_mesh_reset flush pending settings so that the
device can be reprovisioned immediately and the API will behave as
written in the description.
The same applies to bt_mesh_cdb_clear.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Introduce configuration options for chosen RPL implementations.
This will allow introducing alternate persistent storage schemes
for the replay protection list.
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Before this change, enabling CONFIG_BT_SETTINGS and calling
settings_load(), but delaying / not calling bt_enable would trigger an
assertion error due to a timeout. The fault is that the settings load
handler for the Bluetooth host assumes bt_enable has already been called
and sends HCI commands to the controller. This times out if HCI is not
running.
The fix is to skip loading Bluetooth settings before bt_enable. The doc
is updated to guide the user on how to enable Bluetooth after settings
have been loaded before.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
we will no longer need the additional `disconnect` parameter,
such as we only process gatt database from disconnect handler.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
The current approach with storing RPL by timeout doesn't solve all
issues as the node may loss power before the timer is fired.
In addition to that this may wear out flash quickly if short timeout is
used.
This change adds an API to store the pending RPL entry upon user
request. Additional Kconfig option allows to completely disable timer
so that the whole storing relies on the user.
The mesh stack still stays responsible for outdating RPL entries in case
of IV Index update as this happens implicitly for the user.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This adds BT_MESH_SETTINGS_VA_PENDING to GENERIC_PENDING_BITS
as it should be stored by CONFIG_BT_MESH_STORE_TIMEOUT.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This bug was introduced in PR #31176, where setting's flags were
moved out from bt_mesh.flags to pending_flags.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Switch to new work API, taking advantage of the difference between
schedule and reschedule to force an update if the new deadline is
sooner, and retain any previous deadline (or use the new deadline) if
it isn't. Do not leave a path out that could, due to races, fail to
schedule necessary work.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The mesh settings.c module is a giant piece of code responsible for
storing the mesh stack configuration. Such approach makes it difficult
to control the data to be stored, breaks the stack modules'
encapsulation by forcing them to reveal the internal kitchen, which
leads to unpleasant issues such as #19799.
This commit moves the responsibility of storing the configuration
to corresponding modules while keeping control of the moment of storing
the configuration and of starting the stack after the settingss loading
is completed.
This doesn't introduce any abstraction between the mesh settings.c and
other modules as it will add more complexity and overhead than necessary
for the actual task.
Fixes#19850
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Moves mesh feature configuration to a separate module, deprecating the
bt_mesh_cfg_srv structure. The initial values for the features should
now be enabled through KConfig, where new config entries have been added
for each feature.
This removes the upward dependency on the config server from the core
stack, and makes the config server a pure frontend for the configuration
states, as all spec mandated behavior around the feature states is now
encapsulated.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Encapsulates the Heartbeat state and functionality in a separate
heartbeat module, removing all manipulation of the heartbeat state from
the transport and config server modules.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Moves the virtual address labels to the transport layer, disconnecting
them from the configuration server.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
This is a major refactoring of the handling of the cryptographic
material of both the network and transport layers. The aim is to
encapsulate the key object manipulation, and improve overall modularity.
Pulls Applications and Subnets out of the bt_mesh and into separate
modules, with static storage types on the data. This has several
side-effects:
- The Config Server no longer operates directly on the bt_mesh.subs and
bt_mesh.apps lists, but goes through a public configuration interface,
following the pattern set in #27908.
- All iteration through the keys is done through iteration APIs
- Key resolution on RX and TX is centralized.
- Changes to the keys triggers events the other modules can register
handlers for.
- Friendship credentials are stored in the lpn and friend structures.
Part of #27842.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Previous mode store function only can store single data,
change this to store as KV model, let's app-layer to manager
model data, other than by stack when node reset.
Signed-off-by: Lingao Meng <mengabc1086@gmail.com>
Convert bluetooth mesh to using k_timeout struct. Many of the mesh
modules uses timeout calculations, so it is most practical to keep
the s32_t type and only initialize a k_timeout_t struct when
calling the kernel.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Refactor the handling of network nodes and their keys into a separate
Mesh Configuration Database (CDB). This, not only creates a separation
of the local node and the other nodes, but also makes it possible to
implement functions to manage the whole, or at least parts of the mesh
network.
Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
Replaces the Mesh model settings_commit callback with a start callback,
indicating that the mesh model behavior is ready to start. Everything
that was previously done in the settings_commit callback may be moved to
this callback, which gets called just after mesh settings are committed,
instead of in the middle of the process.
This resolves an issue where models had no context in which to start
their behavior, as the previous settings_commit call fired before the
mesh was declared valid, making access APIs inaccessible.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Use 24-bit functions for byteorder and net_buf in order to make the
byteorder used more readable.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
Adds the model extension concept to the access layer, as described in
the Mesh Profile Specification, Section 2.3.6. Extensions are
implemented as a tree, using two pointers in each model:
The extends pointer points to the first extended model, and the next
pointer points to the next sibling or (if the NEXT_IS_PARENT flag is
set) the parent model in the tree, forming a cyclical "Left-child
right-sibling" (LCRS) tree. The tree root can be obtained by calling
bt_mesh_model_root_get(), and the extended models can be walked by
calling bt_mesh_model_tree_walk().
According to the Mesh Profile Specification Section 4.2.3, all models in
the same extension tree share one subscription list per element. This is
implemented by walking the model's extension tree, and pooling the
subscription lists of all models in the same element into one. If the
config server adds a subscription to a model, it may be stored in any of
the model tree's models' subscription lists. No two models in the same
extension tree and element will have duplicate groups listed. This
allows us to increase extended models' capacity for subscriptions
significantly.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Make it possible to provision devices over advertising bearer (PB-ADV).
Many messages in the provisioning protocol are the same for provisioner
and device so much of the code could be reused by only changing when
they are expected to arrive.
This introduces to concept of local and remote device keys. The models
for cfg_cli and cfg_srv have been updated to reflect this concept. Both
the send and receive path in the transport layer have been updated to
support encrypting/decrypting with local and remote device keys.
When a node has been provisioned it is stored in bt_mesh_net.nodes. If
CONFIG_BT_SETTINGS is enabled, they are also saved to settings. If the
callback node_added in bt_mesh_prov has been set, it will be called for
every node that gets provisioned. This includes when they are retrieved
from settings.
The configuration CONFIG_BT_MESH_NODE_COUNT controls how many nodes that
can be provisioned.
Signed-off-by: Tobias Svehagen <tobias.svehagen@gmail.com>
The 16-bit format group addresses will be stored,
but we don't store (or restore) the virtual label UUIDs,
i.e. after a power cycle the 16-bit group addresses
would be meaningless.
Fixes#19342
Signed-off-by: Lingao Meng <mengabc1086@gmail.com>
Adds additional model callback that gets called on node_reset. Will also
erase any user data when this happens.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Adds user data file in the model settings, allowing each model instance
to store some application specific data without having to reinvent the
settings path encoding for model element/ID combinations. Exposes the
settings_handler interface in the model callback structure and adds a
data store function.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
