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 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>
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>
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>
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>
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>
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>
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>
We've already got GATT services in subsys/bluetooth/services so
subsys/bluetooth/mesh is a more natural place. Aditionally this aims
to fix the Kconfig dependencies to be able to use mesh together with
BT_CUSTOM (i.e. a custom, potentially non-HCI, host stack).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
