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>
