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>
Provides utility function for parsing network headers outside of the
network layer. The primary intended use-case is friendship.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Static variables and functions don't need #ifdefs if the code calling
them is using IS_ENABLED(). If IS_ENABLED() evaluates to false the
compiler will strip out all the static entities.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Fix calling bt_hex and bt_addr_le_str multiple times in the same logging
call could result in string overwritten since log_strdup is not
guaranteed to duplicate the string buffer in all logging configurations.
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
When in Low Power mode an LPN may receive messages sent by nodes other
than its friend during its brief receive window. These messages get
rejected by the transport layer. At some point in the future the LPN
will receive these messages from its friend, however they will have
already been added to the network message cache earlier.
When the transport layer rejects a message due to it being received from
a non-friend node while in Low Power mode it must be removed from the
network message cache so that it can be correctly received from its
friend in the future.
Fixes#17809
Signed-off-by: Rich Barlow <rich@bennellick.com>
The commit 1c7b668804 tried to fix
resending segments to the GATT bearer, however it got the buffer
refernce counting wrong. The bt_mesh_net_resend() function doesn't
own a reference to the buffer, i.e. it's not responsible for unrefing
it. E.g. bt_mesh_adv_send() takes its own reference.
What was missing however was the handling of the callbacks. Use the
recently introduced send_cb_finalize() helper to make sure they're
called.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
There are several places that require the send callbacks to be called
immediately. Reduce the code a bit by introducing a helper for this.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Mesh Profile Specification states in section 3.10.5 IV Update
procedure: "The IV Update procedure is initiated by any node that is a
member of a primary subnet", meaning if we're not on the primary
subnet we should not try to initiate the procedure.
Additionally this fixes initiating IV Update in all cases where the
sequence is updated, by putting the code into bt_mesh_next_seq().
Fixes#17977
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The GATT bearer is a reliable one so there should theoretically never
be a need to resend segments. If however for some strange reason the
proxy client doesn't immediately ack all segments we should do the
resending on the GATT bearer, rather than sending them over
advertising.
Fixes#17907
Signed-off-by: Johan Hedberg <johan.hedberg@intel.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>
