Move the network buffer header file from zephyr/net/buf.h to
zephyr/net_buf.h as the implementation now lives outside of the networking
subsystem.
Add (deprecated) zephyr/net/buf.h header to maintain compatibility with old
file path.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
Commit renames deprecated key refresh field.
It still has to exist to allow backward compatibility
with previous versions when data are restored from
the persistent memory.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
Updates Bluetooth mesh specification references:
- Change "Profile" to "Protocol" since the main specification has
changed its name.
- Update/align formating of specification references. This will
make it easier to find spec references in the future.
- Change some section references to point to the correct section of the
newest version of the specification (v1.1).
Signed-off-by: Anders Storrø <anders.storro@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>
According to section 6.7, upon connection Proxy Server shall determine
value of Proxy Privacy parameter (sections 6.5 and 7.2.2.2.6). Depending
on that, it will either send Secure Network Beacon or Private Beacon to
Proxy Client, but never both.
Proxy Privacy parameter is determined by GATT Proxy, Node Identity
states and their private counterparts (section 7.2.2.2.6). Since
non-private and private states are mutually exclusive, it is enough to
only check either Private GATT Proxy state or Private Node Identity
state of any known subnet for which the state is currenty enabled.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Fix binding between GATT Proxy, Node Identity and their private
counterpart states according to sections 4.2.45.1 and 4.2.46.1
accordingly. When non-private state is enabled, the private counterpart
is disabled. The reverse binding prohibits change of non-private state.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@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>
Private Beacons and Secure Network Beacons are not mutually exclusive by
spec. This means both beacons can be sent simultaneously. For both
beacons spec defines their own observation intervals and related
parameters, which means we need to monitor both beacons types
separately.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Adds support for private beacon sending and receiving.
Co-authored-by: Krzysztof Kopyściński <krzysztof.kopyscinski@codecoup.pl>
Co-authored-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
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>
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>
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>
bt_mesh_subnet_find calls a callback for every subnet, and returns the
subnet that got a non-zero return code from the callback. As pointed out
in #41693, the callback should return a boolean, not an int.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
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>
Adds defines for ECC public keys, private keys, DH keys and key
coordinates. Replaces raw numbers throughout.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@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>
While the friend node considers the friendship established as soon as it
sends the friendship offer, the LPN only considers the friendship
established once it receives the first update after its poll. This
update is encrypted with the friendship credentials, which aren't
available, as they're protected by an if (lpn_established()) check.
Changes the check to lpn_waiting_update(), which makes the LPN check its
friendship credentials only when it's expecting a response to a poll
message. This is the only time the friend will send messages encrypted
with the friendship credentials.
This is a regression from #28511.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Since first poll request send by lpn use friend security
credentials, so, friend nodes should be able to decrypt with
friend security, even if they have not yet established a friendship.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Missing copy net_idx to ctx, this cause tx subnet not found
or different with rx subnet, when rx subnet net_idx not zero.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Only set friend_cred to true when friendship established and
use friend cred security material decryption successfully.
Signed-off-by: Lingao Meng <mengabc1086@gmail.com>
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>
