- Before updating the "beacon_sent" of a subnet, we need to check
if the subnet still exists, especially for a Provisioner.
- Fix a bug which will cause Provisioner failed to send Secure
Network Beacon if no device is provisioned
- This issue was introduced in the commit: a788e7cd3d
which updated the bt_hex() function incorrectly.
- And in bt_hex(), we use 2 for the two-dimensional array, because currently
at most two bt_hex() will be used at the same time. Also this will save
some DRAM compared with using 4.
Previously the model recv operation is a littl fuzzy.
With the changes, the model recv operation is splitted into:
- find op
- check app_idx
- check dst
- check length
- update info & handle message
The transport segmented TX nack and seg_pending fields must be at least
6 bits to avoid overflow for 32 segment messages. This change rearranges
the seg_tx fields to gather all state flag fields in one byte, while
making the counter fields whole bytes.
Ensures that friend messages are enqueued, even if the packet is
received with an appkey is unknown to the friend. Previously, sdu_recv
would return EINVAL if the appkey was unknown, which would prevent the
lower transport layer from adding the packet to the friend queue. This
is irrelevant for the logic in lower transport, and should not be
returned as an error.
Device name will be reset when deinit mesh stack. If not
initializing device name during the next mesh stack init,
it will fail to set the device name when using bluedroid.
Since bt_mesh_friend_init() will only be invoked when
a device is provisioned or Provisioner is enabled, so
we add a flag to indicate if the friend functionality
is initialized in case deinit before initialization.
Old version of BLE Mesh has no device role storage, because
previously we only support storing mesh node info.
If the binary of the node is upgraded from old version to a
new version (support storing provisioner info), the mesh info
of the node will not be restored because mesh role does not
exist in the flash.
When fast provisioning is enabled, Provisioner shall not
ignore messages from the nodes whose addresses are not in
the provisioning database. Because other nodes which are
not provisioned by the Primary Provisioner will send node
address messages to the Primary Provisioner.
When using fast provisioning, the Provisioner functionality
will be enabled. Unicast addresses within the pre-allocated
range will be used for provisioning nodes. And during the
address assignment, the allocated unicast address will be
checked that if it's duplicated with other nodes addresses
and the Provisioner's own addresses.
So before starting using fast provisioning, we need to update
the Provisioner address.
