* Fix the issue that deinit node with "erase_flash"
set to true, but info is not erased from nvs
* Reuse bt_mesh_cfg_reset() when deinit node
* Optimize Provisioner related erase operations
* No store pending timeout will be used when Node
is not provisioned OR Provisioner is disabled
and erase operation is performed
* Change the default timeout for settings operation
to 0, and rpl store rate to 0
When reset the rx info of transport layer, the
rpl list will always cleared, and rpl stored
in the nvs will only be erased when erase flag
is true and BLE_MESH_SETTINGS is enabled.
Compared with the previous solution, it should
be more clear.
Since we have provided separate functions for deleting node
information with node's unicast address, device uuid, etc.
So we update the behavior of this function, which will only
be used to delete device information which is not provisioned
or just under provisioning.
Provisioner should always uses the latest IV Index for provisioning.
For example, if the current IV Index is 0x00000001, but prov->iv_index
is still initialized with 0x00000000, and if Provisioner uses prov->
iv_index for provisioning, this will cause the Provisioner failing to
control the node.
So here bt_mesh.iv_index is used instead of prov->iv_index.
- Previously when a model is initialized or deinitialized, in the
access layer, we need to check the model id with the ids in the
table in order to find the proper model operation function.
- Currently all the operation functions of each model will be set
during the mesh initialization. When the model is found, we can
directly use the corresponding callback for different operations.
- Currently only init/deinit operations are registered, later we
will add more operations.
Currently only keep func pointer for the followings:
- Invalid parameter (mesh btc & mesh stack)
- Out of memory (mesh btc & mesh stack)
- Unknown act (mesh btc)
- Invalid model user data (mesh stack)
- BT_DBG("%s", __func__) (mesh btc & mesh stack)
- A few other specific situations (buf ref debug, send status check)
Different bluetooth host has different behaviors, so it's better
to maintain a scan check mechanism of BLE Mesh itself.
Fixes an issue when only PB-GATT is enabled for node, which will
output a scan error log when the device is provisioned.
Update send_ttl mainly for server models. When a server model
receives a message, and the status is required to be replied
by the application, we need to set send_ttl to the msg context.
If send_ttl is not updated in btc, and the applcation does not
set the TTL either, then the status will be replied with TTL=0,
which may cause the client side (e.g. the phone App) failed to
receive the status.
Closes https://github.com/espressif/esp-idf/issues/5300
Also remove some redundant CONFIG_BLE_MESH_PROXY checks, because
when the following options are satisfied, the CONFIG_BLE_MESH_PROXY
option will be selected mandatorily.
ctx values to cb_params for the mesh stack.
recv_rssi was not copied.
This means the rssi could not be read when receiving generic server messages using ble_mesh.
- 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
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
- 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.
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.
Since the behavior of sending segmented messages has been
changed properly, the calculation of timeout value which
will be used when sending an acknowledged message by a
client model also needs to be updated.
Add mutex to protect some variables of the mesh segmented
messages.
Currently the timeout handler of mesh will be executed in
the btc task, while the received mesh messages will be
handled in the btu task. In case some variables are set to
NULL when handled in the btu task, meanwhile these variables
are also accessed in the timeout handler, so we add mutex to
protect these variables and related operations.
