If, while storing app or net key, or changing cdb, we receive another
mesh message that affects setting of the same key that the mesh
currently stores, the new change won't be stored.
The settings subsystem API has rescheduling point inside. The mesh
settings are stored in the system workqueue and by default mesh messages
are processed from BT RX thread which has higher priority than the
system workqueue.
When the case above happens, a new change will be written to the same
cache entry. But this cache entry will be invalidated after leaving
settings API, which in turns will invalidate the new change:
- Receive Config AppKey Add message
cfg_srv.c -> app_keys.c: bt_mesh_app_key_add()
app_keys.c: update_app_key_settings()
app_keys.c: bt_mesh_settings_store_schedule()
- store_pending() in settings.c is scheduled
settings.c -> app_keys.c: bt_mesh_app_key_pending_store()
app_keys.c: store_app_key() called to store new app key
app_keys.c: settings_save_one() calls flash driver and sleeps
- Receive Config AppKey Delete message while in sleep,
which wakes up BT RX thread before returning to the system workqueue
cfg_srv.c -> app_keys.c: bt_mesh_app_key_del()
app_keys.c: update_app_key_settings()
app_keys.c: app_key_update_find() finds entry and returns it
app_keys.c: update->clear = 1
app_keys.c: bt_mesh_settings_store_schedule()
- returning back to bt_mesh_app_key_pending_store() from
settings_save_one()
app_keys.c: update->valid = 0
- the key won't be deleted next time store_pending() is scheduled.
This change moves entry invalidation before calling settings API so that
after returning from settings API, a new change won't be unintentionally
invalidated.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
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>
Functions related to string manipulation that were defined in
`common/log.h` has been moved to the `common/bt_str.h` file and their
implementation in `common/bt_str.c`.
Files that were using those functions has been updated consequently.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
Logging v1 has been removed and log_strdup wrapper function is no
longer needed. Removing the function and its use in the tree.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@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>
The signature of bt_mesh_app_key_resolve expresses pointer to a 16 byte
array as a const uint8_t *app_key[16], which is actually an array of 16
byte pointers. The intended type is equivalent to a double pointer to
const uint8_t, but trips up GCC 11, which actually checks this.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
There is a problem with the previous method, that is,
we use the same label(bt_mesh_subnet_cb_subnet_evt) and
put it in the same section, which is not friendly for debugging.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
This migrates all the current iterable section usages to the external
API, dropping the "Z_" prefix:
Z_ITERABLE_SECTION_ROM
Z_ITERABLE_SECTION_ROM_GC_ALLOWED
Z_ITERABLE_SECTION_RAM
Z_ITERABLE_SECTION_RAM_GC_ALLOWED
Z_STRUCT_SECTION_ITERABLE
Z_STRUCT_SECTION_ITERABLE_ALTERNATE
Z_STRUCT_SECTION_FOREACH
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
The latest MESH.TS 1.0.1.2 4.15.10 Appkey List Procedures
MESH/NODE/CFG/AKL/BI-04-C
Verify that the IUT can respond to an Config AppKey Add
message with NetKeyIndex and AppKeyIndex already stored.
6. Repeat step 1 with the same AppKey, the same
AppKeyIndex, but NetKeyIndex field set to 0x001.
7. The Lower Tester expects the IUT to respond
with an Config AppKey Status message with the
Status field set to 0x04 (Invalid NetKey) and
the NetKeyIndex and AppKeyIndex values equal to
those sent in step 5.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Added bt_mesh_msg_send() which can be used by the application to
directly send model layer messages without local instantiation of
related models. Also added bt_mesh_msg_cb_set() which allows the
application to recieve mesh model layer messages without local
instantiation of related models.
Added bt_mesh_has_addr() which returns a bool. For unicast addresses,
this returns whether or not bt_mesh_elem_find() was successfull. If the
above mentioned bt_mesh_msg_cb_set() has been used by the application to
set a message callback, this returns true so that the stack attempts to
push every model message up to the application via the callback. If no
callback has been set, group addresses are searched to see if the stack
should pass the message up the stack to an instantiated model.
These changes allow applications that do not or can not instantiate
models to interface with models in a mesh network. This is applicable to
applications which act as a Bluetooth mesh gateway, sniffer, debugger,
network monitoring, non-mesh relay/extender, etc.
In app_keys.c friend.c net.c bt_mesh_elem_find() is used only to
determine the existance of an address. The full return value of
bt_mesh_elem_find() is unecessary and so was replaced by the above
mentioned bt_mesh_has_addr() function in these instances.
Simplified bt_mesh_elem_find() by removing the search through group
address. Since the above mentioned bt_mesh_has_addr() function handles
instances where group addresses must be searched, it was no longer
necessary to preform this search in this function.
Signed-off-by: Bud Wandinger <bud@budkoembedded.ca>
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>
