2021-06-08 09:32:13 +02:00
|
|
|
# Bluetooth mesh configuration options
|
2017-06-16 12:30:54 +03:00
|
|
|
|
|
|
|
# Copyright (c) 2017 Intel Corporation
|
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
menuconfig BT_MESH
|
2021-06-08 09:32:13 +02:00
|
|
|
bool "Bluetooth mesh support"
|
2017-06-16 12:30:54 +03:00
|
|
|
select TINYCRYPT
|
|
|
|
select TINYCRYPT_AES
|
|
|
|
select TINYCRYPT_AES_CMAC
|
2020-01-29 13:03:23 +01:00
|
|
|
select BT_HOST_CCM
|
2018-06-27 08:54:54 +02:00
|
|
|
depends on BT_OBSERVER && BT_BROADCASTER
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
2021-06-08 09:32:13 +02:00
|
|
|
This option enables Bluetooth mesh support. The specific
|
2017-11-10 14:08:09 +02:00
|
|
|
features that are available may depend on other features
|
|
|
|
that have been enabled in the stack, such as GATT support.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
if BT_MESH
|
2017-06-16 12:30:54 +03:00
|
|
|
|
|
|
|
# Virtual option enabled whenever Generic Provisioning layer is needed
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_PROV
|
2017-06-16 12:30:54 +03:00
|
|
|
bool
|
|
|
|
|
2020-09-17 13:47:37 +08:00
|
|
|
config BT_MESH_PROV_DEVICE
|
|
|
|
bool "Provisioning device role support"
|
|
|
|
depends on BT_MESH_PROV
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable this option to allow the device to be provisioned into a mesh network.
|
|
|
|
|
2021-06-09 11:01:57 +02:00
|
|
|
config BT_MESH_PROV_OOB_PUBLIC_KEY
|
|
|
|
bool "OOB Public key support"
|
|
|
|
select TINYCRYPT_ECC_DH
|
|
|
|
depends on BT_MESH_PROV_DEVICE
|
|
|
|
help
|
|
|
|
Enable this option if public key is to be exchanged via Out of Band (OOB) technology.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_PB_ADV
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Provisioning support using the advertising bearer (PB-ADV)"
|
2017-08-09 09:21:11 +03:00
|
|
|
select BT_MESH_PROV
|
2017-06-16 12:30:54 +03:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable this option to allow the device to be provisioned over
|
|
|
|
the advertising bearer.
|
|
|
|
|
2020-08-10 10:55:21 +08:00
|
|
|
config BT_MESH_UNPROV_BEACON_INT
|
2020-09-01 15:17:27 +03:00
|
|
|
int
|
|
|
|
prompt "The interval (in seconds) to send the unprovisioned beacon" if BT_MESH_PB_ADV
|
2020-08-10 10:55:21 +08:00
|
|
|
default 5
|
|
|
|
range 1 10
|
|
|
|
help
|
|
|
|
This option specifies the interval (in seconds) at which the
|
|
|
|
device sends unprovisioned beacon.
|
|
|
|
|
2020-09-04 09:51:39 +08:00
|
|
|
config BT_MESH_PB_ADV_RETRANS_TIMEOUT
|
|
|
|
int "Timeout value of retransmit provisioning PDUs"
|
|
|
|
default 500
|
|
|
|
range 100 800
|
|
|
|
help
|
|
|
|
Timeout value of retransmit provisioning PDUs.
|
|
|
|
|
2019-07-12 15:57:58 +02:00
|
|
|
config BT_MESH_PROVISIONER
|
|
|
|
bool "Provisioner support"
|
2020-09-17 13:47:37 +08:00
|
|
|
depends on BT_MESH_PROV
|
2022-02-07 17:25:09 +08:00
|
|
|
depends on BT_MESH_PB_ADV || BT_MESH_PB_GATT_CLIENT
|
2019-07-12 15:57:58 +02:00
|
|
|
help
|
|
|
|
Enable this option to have support for provisioning remote devices.
|
|
|
|
|
2019-11-04 16:14:07 +01:00
|
|
|
config BT_MESH_CDB
|
|
|
|
bool "Mesh Configuration Database [EXPERIMENTAL]"
|
2020-09-17 13:47:37 +08:00
|
|
|
default y if BT_MESH_PROVISIONER
|
2021-10-15 14:14:16 +02:00
|
|
|
select EXPERIMENTAL
|
2019-07-12 15:57:58 +02:00
|
|
|
|
2019-11-04 16:14:07 +01:00
|
|
|
if BT_MESH_CDB
|
|
|
|
|
|
|
|
config BT_MESH_CDB_NODE_COUNT
|
|
|
|
int "Maximum number of nodes in the database"
|
2021-06-10 16:20:17 +02:00
|
|
|
default 8
|
2019-07-12 15:57:58 +02:00
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many nodes each network can at most
|
2019-11-04 16:14:07 +01:00
|
|
|
save in the configuration database.
|
2019-07-12 15:57:58 +02:00
|
|
|
|
2019-11-04 16:14:07 +01:00
|
|
|
config BT_MESH_CDB_SUBNET_COUNT
|
|
|
|
int "Maximum number of subnets in the database"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many subnets that can at most be
|
|
|
|
saved in the configuration database.
|
|
|
|
|
|
|
|
config BT_MESH_CDB_APP_KEY_COUNT
|
|
|
|
int "Maximum number of application keys in the database"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many application keys that can at most
|
|
|
|
be saved in the configuration database.
|
|
|
|
|
|
|
|
endif # BT_MESH_CDB
|
2019-07-12 15:57:58 +02:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
if BT_CONN
|
2017-06-16 12:30:54 +03:00
|
|
|
|
|
|
|
# Virtual option enabled whenever any Proxy protocol is needed
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_PROXY
|
2017-06-16 12:30:54 +03:00
|
|
|
bool
|
2021-06-25 00:12:38 -07:00
|
|
|
|
|
|
|
config BT_MESH_GATT
|
|
|
|
bool
|
|
|
|
|
2021-09-09 14:41:15 +08:00
|
|
|
config BT_MESH_PROXY_MSG_LEN
|
|
|
|
int
|
2022-03-02 14:26:55 +08:00
|
|
|
default 66 if BT_MESH_PB_GATT_COMMON
|
2021-09-09 14:41:15 +08:00
|
|
|
default 33 if BT_MESH_GATT_PROXY
|
2022-03-02 14:26:55 +08:00
|
|
|
depends on BT_MESH_GATT
|
2021-09-09 14:41:15 +08:00
|
|
|
|
2022-02-07 17:13:02 +08:00
|
|
|
config BT_MESH_GATT_CLIENT
|
|
|
|
bool
|
|
|
|
select BT_MESH_GATT
|
|
|
|
|
2021-06-25 00:12:38 -07:00
|
|
|
config BT_MESH_GATT_SERVER
|
|
|
|
bool
|
|
|
|
select BT_MESH_GATT
|
2019-04-25 11:23:14 +03:00
|
|
|
select BT_GATT_DYNAMIC_DB
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2022-02-07 17:25:09 +08:00
|
|
|
config BT_MESH_PB_GATT_COMMON
|
|
|
|
bool
|
|
|
|
|
|
|
|
config BT_MESH_PB_GATT_CLIENT
|
|
|
|
bool "Provisioner support using GATT (PB-GATT)"
|
|
|
|
select BT_MESH_PROV
|
|
|
|
select BT_GATT_CLIENT
|
|
|
|
select BT_MESH_GATT_CLIENT
|
|
|
|
select BT_MESH_PB_GATT_COMMON
|
|
|
|
select BT_MESH_PROVISIONER
|
|
|
|
depends on BT_CENTRAL
|
|
|
|
help
|
|
|
|
Enable this option to allow the provisioner provisioning the
|
|
|
|
device over GATT.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_PB_GATT
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Provisioning support using GATT (PB-GATT)"
|
2021-06-25 00:12:38 -07:00
|
|
|
select BT_MESH_GATT_SERVER
|
2017-08-09 09:21:11 +03:00
|
|
|
select BT_MESH_PROV
|
2022-02-07 17:25:09 +08:00
|
|
|
select BT_MESH_PB_GATT_COMMON
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
Enable this option to allow the device to be provisioned over
|
|
|
|
GATT.
|
|
|
|
|
2021-09-04 09:00:53 +08:00
|
|
|
config BT_MESH_PB_GATT_USE_DEVICE_NAME
|
|
|
|
bool "Include Bluetooth device name in scan response"
|
|
|
|
depends on BT_MESH_PB_GATT
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option includes GAP device name in scan response when
|
|
|
|
the PB-GATT is enabled.
|
|
|
|
|
2022-02-07 17:13:02 +08:00
|
|
|
config BT_MESH_PROXY_CLIENT
|
|
|
|
bool "Proxy client support"
|
|
|
|
select BT_GATT_CLIENT
|
|
|
|
select BT_MESH_GATT_CLIENT
|
|
|
|
depends on BT_CENTRAL
|
|
|
|
help
|
|
|
|
This option enables support for the Mesh GATT Proxy Client,
|
|
|
|
i.e. the ability to act as a proxy between a Mesh GATT Service
|
|
|
|
and a Mesh network.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_GATT_PROXY
|
2020-08-18 13:36:38 +02:00
|
|
|
bool "GATT Proxy Service support"
|
2021-06-25 00:12:38 -07:00
|
|
|
select BT_MESH_GATT_SERVER
|
2017-08-09 09:21:11 +03:00
|
|
|
select BT_MESH_PROXY
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
This option enables support for the Mesh GATT Proxy Service,
|
|
|
|
i.e. the ability to act as a proxy between a Mesh GATT Client
|
|
|
|
and a Mesh network.
|
|
|
|
|
2020-08-18 13:36:38 +02:00
|
|
|
config BT_MESH_GATT_PROXY_ENABLED
|
|
|
|
bool "GATT Proxy enabled"
|
|
|
|
depends on BT_MESH_GATT_PROXY
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Controls whether the GATT Proxy feature is enabled by default.
|
|
|
|
Can be changed through runtime configuration.
|
|
|
|
|
2017-11-27 12:59:55 +02:00
|
|
|
config BT_MESH_NODE_ID_TIMEOUT
|
|
|
|
int "Node Identity advertising timeout"
|
|
|
|
depends on BT_MESH_GATT_PROXY
|
|
|
|
range 1 60
|
|
|
|
default 60
|
|
|
|
help
|
|
|
|
This option determines for how long the local node advertises
|
|
|
|
using Node Identity. The given value is in seconds. The
|
|
|
|
specification limits this to 60 seconds, and implies that to
|
|
|
|
be the appropriate value as well, so just leaving this as the
|
|
|
|
default is the safest option.
|
|
|
|
|
2021-06-25 00:12:38 -07:00
|
|
|
config BT_MESH_PROXY_USE_DEVICE_NAME
|
|
|
|
bool "Include Bluetooth device name in scan response"
|
|
|
|
depends on BT_MESH_GATT_PROXY
|
|
|
|
help
|
|
|
|
This option includes GAP device name in scan response when
|
|
|
|
the GATT Proxy feature is enabled.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_PROXY_FILTER_SIZE
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Maximum number of filter entries per Proxy Client"
|
2021-08-18 16:56:31 +08:00
|
|
|
default 3
|
2017-06-16 12:30:54 +03:00
|
|
|
range 1 32767
|
2021-08-18 16:56:31 +08:00
|
|
|
depends on BT_MESH_GATT_PROXY
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
This option specifies how many Proxy Filter entries the local
|
|
|
|
node supports.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
endif # BT_CONN
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2021-05-29 13:18:10 -06:00
|
|
|
config BT_MESH_ACCESS_LAYER_MSG
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Direct Bluetooth message access layer messages"
|
2021-05-29 13:18:10 -06:00
|
|
|
help
|
2022-03-16 21:07:43 +00:00
|
|
|
This option allows the application to directly access
|
2021-05-29 13:18:10 -06:00
|
|
|
Bluetooth access layer messages without the need to
|
|
|
|
instantiate Bluetooth mesh models.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_SELF_TEST
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Perform self-tests"
|
|
|
|
help
|
|
|
|
This option adds extra self-tests which are run every time
|
|
|
|
mesh networking is initialized.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_IV_UPDATE_TEST
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Test the IV Update Procedure"
|
|
|
|
help
|
|
|
|
This option removes the 96 hour limit of the IV Update
|
|
|
|
Procedure and lets the state be changed at any time.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_SUBNET_COUNT
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Maximum number of mesh subnets per network"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many subnets a Mesh network can
|
|
|
|
participate in at the same time.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_APP_KEY_COUNT
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Maximum number of application keys per network"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many application keys the device can
|
|
|
|
store per network.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_MODEL_KEY_COUNT
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Maximum number of application keys per model"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many application keys each model can
|
|
|
|
at most be bound to.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_MODEL_GROUP_COUNT
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Maximum number of group address subscriptions per model"
|
|
|
|
default 1
|
|
|
|
range 1 4096
|
|
|
|
help
|
|
|
|
This option specifies how many group addresses each model can
|
|
|
|
at most be subscribed to.
|
|
|
|
|
2021-05-08 02:49:54 -07:00
|
|
|
config BT_MESH_MODEL_VND_MSG_CID_FORCE
|
|
|
|
bool "Force vendor model to use the corresponding CID field message"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option forces vendor model to use messages for the
|
|
|
|
corresponding CID field.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_LABEL_COUNT
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Maximum number of Label UUIDs used for Virtual Addresses"
|
|
|
|
default 1
|
|
|
|
range 0 4096
|
|
|
|
help
|
|
|
|
This option specifies how many Label UUIDs can be stored.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_CRPL
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Maximum capacity of the replay protection list"
|
|
|
|
default 10
|
|
|
|
range 2 65535
|
|
|
|
help
|
|
|
|
This options specifies the maximum capacity of the replay
|
|
|
|
protection list. This option is similar to the network message
|
|
|
|
cache size, but has a different purpose.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_MSG_CACHE_SIZE
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Network message cache size"
|
|
|
|
default 10
|
|
|
|
range 2 65535
|
|
|
|
help
|
|
|
|
Number of messages that are cached for the network. This helps
|
|
|
|
prevent unnecessary decryption operations and unnecessary
|
|
|
|
relays. This option is similar to the replay protection list,
|
|
|
|
but has a different purpose.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_ADV_BUF_COUNT
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Number of advertising buffers"
|
|
|
|
default 6
|
2020-07-10 11:10:55 +02:00
|
|
|
range 1 256
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
2018-07-23 20:47:12 +03:00
|
|
|
Number of advertising buffers available. This should be chosen
|
2018-08-07 14:03:09 -07:00
|
|
|
based on what kind of features the local node should have. E.g.
|
2018-07-23 20:47:12 +03:00
|
|
|
a relay will perform better the more buffers it has. Another
|
|
|
|
thing to consider is outgoing segmented messages. There must
|
|
|
|
be at least three more advertising buffers than the maximum
|
|
|
|
supported outgoing segment count (BT_MESH_TX_SEG_MAX).
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2020-11-13 16:21:32 +01:00
|
|
|
choice BT_MESH_ADV
|
|
|
|
prompt "Advertiser mode"
|
|
|
|
default BT_MESH_ADV_EXT if BT_EXT_ADV
|
|
|
|
default BT_MESH_ADV_LEGACY
|
|
|
|
|
|
|
|
config BT_MESH_ADV_LEGACY
|
|
|
|
bool "Legacy advertising"
|
|
|
|
help
|
|
|
|
Use legacy advertising commands for mesh sending. Legacy
|
|
|
|
advertising is significantly slower than the extended advertising, but
|
|
|
|
is supported by all controllers.
|
|
|
|
|
|
|
|
config BT_MESH_ADV_EXT
|
|
|
|
bool "Extended advertising"
|
|
|
|
depends on BT_CTLR_ADV_EXT || !BT_CTLR
|
|
|
|
depends on BT_EXT_ADV
|
|
|
|
help
|
|
|
|
Use extended advertising commands for operating the advertiser.
|
|
|
|
Extended advertising is faster and uses less memory than legacy
|
|
|
|
advertising, but isn't supported by all controllers.
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
2021-11-03 17:05:10 +08:00
|
|
|
if BT_MESH_ADV_EXT
|
|
|
|
|
|
|
|
config BT_MESH_RELAY_ADV_SETS
|
|
|
|
int "Maximum of simultaneous relay message support"
|
|
|
|
default 0
|
|
|
|
range 0 BT_EXT_ADV_MAX_ADV_SET
|
|
|
|
depends on BT_MESH_RELAY
|
|
|
|
help
|
|
|
|
Maximum of simultaneous relay message support. Requires controller support
|
|
|
|
multiple advertising sets.
|
|
|
|
|
|
|
|
config BT_MESH_ADV_EXT_GATT_SEPARATE
|
|
|
|
bool "Use a separate extended advertising set for GATT Server Advertising"
|
|
|
|
depends on BT_MESH_GATT_SERVER
|
|
|
|
help
|
|
|
|
Use a separate extended advertising set for GATT Server Advertising,
|
|
|
|
otherwise will be used a shared advertising set.
|
|
|
|
|
|
|
|
endif # BT_MESH_ADV_EXT
|
|
|
|
|
2020-07-30 17:48:12 +08:00
|
|
|
config BT_MESH_ADV_STACK_SIZE
|
|
|
|
int "Mesh advertiser thread stack size"
|
2020-11-13 16:21:32 +01:00
|
|
|
depends on BT_MESH_ADV_LEGACY
|
2020-07-30 17:48:12 +08:00
|
|
|
default 1024 if BT_HOST_CRYPTO
|
|
|
|
default 768
|
|
|
|
help
|
2021-07-28 03:57:35 -07:00
|
|
|
Size of bt mesh adv thread stack.
|
|
|
|
|
2020-07-30 17:48:12 +08:00
|
|
|
NOTE: This is an advanced setting and should not be changed unless
|
|
|
|
absolutely necessary
|
|
|
|
|
2021-07-27 03:56:57 -07:00
|
|
|
config BT_MESH_ADV_PRIO
|
|
|
|
int "Mesh advertiser thread priority"
|
|
|
|
depends on BT_MESH_ADV_LEGACY
|
|
|
|
default 7
|
|
|
|
help
|
|
|
|
Priority of bt mesh adv thread.
|
|
|
|
|
|
|
|
NOTE: This is an advanced setting and should not be changed unless
|
|
|
|
absolutely necessary
|
|
|
|
|
2021-06-09 12:06:55 +08:00
|
|
|
config BT_MESH_IV_UPDATE_SEQ_LIMIT
|
|
|
|
hex "Sequence number limit to start iv update"
|
|
|
|
default 0x800000
|
|
|
|
range 0x000001 0xFFFFFE
|
|
|
|
help
|
|
|
|
This option specifies the sequence number value to start iv update.
|
|
|
|
|
2018-05-15 14:35:07 +03:00
|
|
|
config BT_MESH_IVU_DIVIDER
|
|
|
|
int "Divider for IV Update state refresh timer"
|
|
|
|
default 4
|
|
|
|
range 2 96
|
|
|
|
help
|
|
|
|
When the IV Update state enters Normal operation or IV Update
|
|
|
|
in Progress, we need to keep track of how many hours has passed
|
|
|
|
in the state, since the specification requires us to remain in
|
|
|
|
the state at least for 96 hours (Update in Progress has an
|
|
|
|
additional upper limit of 144 hours).
|
|
|
|
|
2018-05-23 11:53:20 -07:00
|
|
|
In order to fulfill the above requirement, even if the node might
|
2018-05-15 14:35:07 +03:00
|
|
|
be powered off once in a while, we need to store persistently
|
|
|
|
how many hours the node has been in the state. This doesn't
|
|
|
|
necessarily need to happen every hour (thanks to the flexible
|
|
|
|
duration range). The exact cadence will depend a lot on the
|
|
|
|
ways that the node will be used and what kind of power source it
|
|
|
|
has.
|
|
|
|
|
|
|
|
Since there is no single optimal answer, this configuration
|
|
|
|
option allows specifying a divider, i.e. how many intervals
|
|
|
|
the 96 hour minimum gets split into. After each interval the
|
|
|
|
duration that the node has been in the current state gets
|
|
|
|
stored to flash. E.g. the default value of 4 means that the
|
|
|
|
state is saved every 24 hours (96 / 4).
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_TX_SEG_MSG_COUNT
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Maximum number of simultaneous outgoing segmented messages"
|
|
|
|
default 1
|
2022-01-29 16:05:22 +08:00
|
|
|
range 0 255
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
Maximum number of simultaneous outgoing multi-segment and/or
|
|
|
|
reliable messages.
|
|
|
|
|
2022-03-16 21:07:43 +00:00
|
|
|
Note that: Since Mesh Segmentation/reassembling is a mandatory
|
2022-01-29 16:05:22 +08:00
|
|
|
feature of specification, set to zero will not allow send any
|
|
|
|
Mesh Segment message.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_RX_SEG_MSG_COUNT
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Maximum number of simultaneous incoming segmented messages"
|
|
|
|
default 1
|
2022-01-29 16:05:22 +08:00
|
|
|
range 0 255
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
Maximum number of simultaneous incoming multi-segment and/or
|
|
|
|
reliable messages.
|
|
|
|
|
2022-01-29 16:05:22 +08:00
|
|
|
Note that: Since Mesh Segmentation/reassemblying is a mandatory
|
|
|
|
feature of specification, set to zero will not allow receive any
|
|
|
|
Mesh Segment message.
|
|
|
|
|
2020-03-05 16:10:15 +01:00
|
|
|
config BT_MESH_SEG_BUFS
|
|
|
|
int "Number of segment buffers available"
|
|
|
|
default 64
|
|
|
|
range BT_MESH_RX_SEG_MAX 16384 if BT_MESH_RX_SEG_MAX > \
|
|
|
|
BT_MESH_TX_SEG_MAX
|
|
|
|
range BT_MESH_TX_SEG_MAX 16384
|
2018-07-25 15:39:02 +03:00
|
|
|
help
|
2020-03-05 16:10:15 +01:00
|
|
|
The incoming and outgoing segmented messages allocate their
|
|
|
|
segments from the same pool. Each segment is a 12 byte block,
|
|
|
|
and may only be used by one message at the time.
|
|
|
|
|
|
|
|
Outgoing messages will allocate their segments at the start of the
|
|
|
|
transmission, and release them one by one as soon as they have been
|
|
|
|
acknowledged by the receiver. Incoming messages allocate all their
|
|
|
|
segments at the start of the transaction, and won't release them until
|
|
|
|
the message is fully received.
|
|
|
|
|
|
|
|
config BT_MESH_RX_SEG_MAX
|
|
|
|
int "Maximum number of segments in incoming messages"
|
|
|
|
default 3
|
2022-01-29 16:05:22 +08:00
|
|
|
range 1 32
|
|
|
|
depends on BT_MESH_RX_SEG_MSG_COUNT > 0
|
2020-03-05 16:10:15 +01:00
|
|
|
help
|
|
|
|
Maximum number of segments supported for incoming messages.
|
|
|
|
This value should typically be fine-tuned based on what
|
|
|
|
models the local node supports, i.e. what's the largest
|
|
|
|
message payload that the node needs to be able to receive.
|
|
|
|
This value affects memory and call stack consumption, which
|
|
|
|
is why the default is lower than the maximum that the
|
|
|
|
specification would allow (32 segments).
|
|
|
|
|
|
|
|
The maximum incoming SDU size is 12 times this number (out of
|
|
|
|
which 4 or 8 bytes is used for the Transport Layer MIC). For
|
|
|
|
example, 5 segments means the maximum SDU size is 60 bytes,
|
|
|
|
which leaves 56 bytes for application layer data using a
|
|
|
|
4-byte MIC and 52 bytes using an 8-byte MIC.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2018-07-23 20:47:12 +03:00
|
|
|
config BT_MESH_TX_SEG_MAX
|
|
|
|
int "Maximum number of segments in outgoing messages"
|
|
|
|
default 3
|
2022-01-29 16:05:22 +08:00
|
|
|
range 1 32
|
|
|
|
depends on BT_MESH_TX_SEG_MSG_COUNT > 0
|
2018-07-23 20:47:12 +03:00
|
|
|
help
|
|
|
|
Maximum number of segments supported for outgoing messages.
|
|
|
|
This value should typically be fine-tuned based on what
|
|
|
|
models the local node supports, i.e. what's the largest
|
|
|
|
message payload that the node needs to be able to send.
|
2020-03-05 16:10:15 +01:00
|
|
|
This value affects memory consumption, which is why the
|
|
|
|
default is lower than the maximum that the specification
|
|
|
|
would allow (32 segments).
|
2018-07-23 20:47:12 +03:00
|
|
|
|
|
|
|
The maximum outgoing SDU size is 12 times this number (out of
|
|
|
|
which 4 or 8 bytes is used for the Transport Layer MIC). For
|
|
|
|
example, 5 segments means the maximum SDU size is 60 bytes,
|
|
|
|
which leaves 56 bytes for application layer data using a
|
|
|
|
4-byte MIC and 52 bytes using an 8-byte MIC.
|
|
|
|
|
2020-08-18 13:36:38 +02:00
|
|
|
config BT_MESH_DEFAULT_TTL
|
|
|
|
int "Default TTL value"
|
|
|
|
default 7
|
|
|
|
range 0 128
|
|
|
|
help
|
|
|
|
Controls the default TTL value for outgoing messages. Can be changed
|
|
|
|
through runtime configuration.
|
|
|
|
|
2020-07-10 11:10:55 +02:00
|
|
|
config BT_MESH_LOOPBACK_BUFS
|
|
|
|
int "Number of loopback buffers"
|
|
|
|
default 3
|
|
|
|
help
|
|
|
|
The number of buffers allocated for the network loopback mechanism.
|
|
|
|
Loopback is used when the device sends messages to itself.
|
|
|
|
|
2020-09-04 09:51:39 +08:00
|
|
|
config BT_MESH_TX_SEG_RETRANS_COUNT
|
|
|
|
int "Transport message segment retransmit attempts"
|
|
|
|
default 4
|
|
|
|
range 1 8
|
|
|
|
help
|
|
|
|
Maximum number of transport message segment retransmit attempts
|
|
|
|
for outgoing segment message.
|
|
|
|
|
|
|
|
config BT_MESH_TX_SEG_RETRANS_TIMEOUT_UNICAST
|
|
|
|
int "Transport message segment retransmit interval for unicast messages"
|
|
|
|
default 400
|
|
|
|
range 200 500
|
|
|
|
help
|
|
|
|
Maximum time of retransmit segment message to unicast address.
|
|
|
|
|
|
|
|
config BT_MESH_TX_SEG_RETRANS_TIMEOUT_GROUP
|
|
|
|
int "Transport message segment retransmit interval for group messages"
|
|
|
|
default 50
|
|
|
|
range 20 200
|
|
|
|
help
|
|
|
|
Maximum time of retransmit segment message to group address.
|
|
|
|
|
2020-08-18 13:36:38 +02:00
|
|
|
config BT_MESH_NETWORK_TRANSMIT_COUNT
|
|
|
|
int "Network Transmit Count"
|
|
|
|
default 2
|
|
|
|
range 0 7
|
|
|
|
help
|
|
|
|
Controls the initial number of retransmissions of original messages,
|
|
|
|
in addition to the first transmission. Can be changed through runtime
|
|
|
|
configuration.
|
|
|
|
|
|
|
|
config BT_MESH_NETWORK_TRANSMIT_INTERVAL
|
|
|
|
int "Network Transmit Interval"
|
|
|
|
default 20
|
|
|
|
range 10 330
|
|
|
|
help
|
|
|
|
Controls the initial interval between retransmissions of original
|
|
|
|
messages, in milliseconds. Can be changed through runtime
|
|
|
|
configuration.
|
|
|
|
|
|
|
|
menuconfig BT_MESH_RELAY
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Relay support"
|
|
|
|
help
|
|
|
|
Support for acting as a Mesh Relay Node.
|
|
|
|
|
2020-08-18 13:36:38 +02:00
|
|
|
if BT_MESH_RELAY
|
|
|
|
|
|
|
|
config BT_MESH_RELAY_ENABLED
|
|
|
|
bool "Relay enabled"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Controls whether the Mesh Relay feature is enabled by default. Can be
|
|
|
|
changed through runtime configuration.
|
|
|
|
|
|
|
|
config BT_MESH_RELAY_RETRANSMIT_COUNT
|
|
|
|
int "Relay Retransmit Count"
|
|
|
|
default 2
|
|
|
|
range 0 7
|
|
|
|
help
|
|
|
|
Controls the initial number of retransmissions of relayed messages, in
|
|
|
|
addition to the first transmission. Can be changed through runtime
|
|
|
|
configuration.
|
|
|
|
|
|
|
|
config BT_MESH_RELAY_RETRANSMIT_INTERVAL
|
|
|
|
int "Relay Retransmit Interval"
|
|
|
|
default 20
|
|
|
|
range 10 330
|
|
|
|
help
|
|
|
|
Controls the initial interval between retransmissions of relayed
|
|
|
|
messages, in milliseconds. Can be changed through runtime
|
|
|
|
configuration.
|
|
|
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
config BT_MESH_BEACON_ENABLED
|
|
|
|
bool "Secure network beacon enabled"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Controls whether the Secure network beacon feature is enabled by
|
|
|
|
default. Can be changed through runtime configuration.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_LOW_POWER
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Support for Low Power features"
|
|
|
|
help
|
|
|
|
Enable this option to be able to act as a Low Power Node.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
if BT_MESH_LOW_POWER
|
2017-11-09 10:28:44 +02:00
|
|
|
|
|
|
|
config BT_MESH_LPN_ESTABLISHMENT
|
|
|
|
bool "Perform Friendship establishment using low power"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Perform the Friendship establishment using low power, with
|
|
|
|
the help of a reduced scan duty cycle. The downside of this
|
|
|
|
is that the node may miss out on messages intended for it
|
|
|
|
until it has successfully set up Friendship with a Friend
|
|
|
|
node.
|
|
|
|
|
|
|
|
config BT_MESH_LPN_AUTO
|
|
|
|
bool "Automatically start looking for Friend nodes once provisioned"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Automatically enable LPN functionality once provisioned and start
|
|
|
|
looking for Friend nodes. If this option is disabled LPN mode
|
|
|
|
needs to be manually enabled by calling bt_mesh_lpn_set(true).
|
|
|
|
|
|
|
|
config BT_MESH_LPN_AUTO_TIMEOUT
|
|
|
|
int "Time from last received message before going to LPN mode"
|
|
|
|
default 15
|
|
|
|
range 0 3600
|
|
|
|
depends on BT_MESH_LPN_AUTO
|
|
|
|
help
|
|
|
|
Time in seconds from the last received message, that the node
|
|
|
|
will wait before starting to look for Friend nodes.
|
|
|
|
|
|
|
|
config BT_MESH_LPN_RETRY_TIMEOUT
|
|
|
|
int "Retry timeout for Friend requests"
|
|
|
|
default 8
|
|
|
|
range 1 3600
|
|
|
|
help
|
|
|
|
Time in seconds between Friend Requests, if a previous Friend
|
|
|
|
Request did not receive any acceptable Friend Offers.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_LPN_RSSI_FACTOR
|
2017-06-16 12:30:54 +03:00
|
|
|
int "RSSIFactor, used in the Friend Offer Delay calculation"
|
|
|
|
range 0 3
|
|
|
|
default 0
|
|
|
|
help
|
|
|
|
The contribution of the RSSI measured by the Friend node used
|
|
|
|
in Friend Offer Delay calculations. 0 = 1, 1 = 1.5, 2 = 2, 3 = 2.5.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_LPN_RECV_WIN_FACTOR
|
2017-06-16 12:30:54 +03:00
|
|
|
int "ReceiveWindowFactor, used in the Friend Offer Delay calculation"
|
|
|
|
range 0 3
|
|
|
|
default 0
|
|
|
|
help
|
|
|
|
The contribution of the supported Receive Window used in
|
|
|
|
Friend Offer Delay calculations. 0 = 1, 1 = 1.5, 2 = 2, 3 = 2.5.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_LPN_MIN_QUEUE_SIZE
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Minimum size of acceptable friend queue (MinQueueSizeLog)"
|
|
|
|
range 1 7
|
|
|
|
default 1
|
|
|
|
help
|
|
|
|
The MinQueueSizeLog field is defined as log_2(N), where N is
|
|
|
|
the minimum number of maximum size Lower Transport PDUs that
|
|
|
|
the Friend node can store in its Friend Queue. As an example,
|
|
|
|
MinQueueSizeLog value 1 gives N = 2, and value 7 gives N = 128.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_LPN_RECV_DELAY
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Receive delay requested by the local node"
|
|
|
|
range 10 255
|
2017-11-10 10:47:12 +02:00
|
|
|
default 100
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
The ReceiveDelay is the time between the Low Power node
|
|
|
|
sending a request and listening for a response. This delay
|
|
|
|
allows the Friend node time to prepare the response. The value
|
|
|
|
is in units of milliseconds.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_LPN_POLL_TIMEOUT
|
2017-11-23 09:48:41 +02:00
|
|
|
int "The value of the PollTimeout timer"
|
2017-06-16 12:30:54 +03:00
|
|
|
range 10 244735
|
2017-11-23 09:48:41 +02:00
|
|
|
default 300
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
PollTimeout timer is used to measure time between two
|
|
|
|
consecutive requests sent by the Low Power node. If no
|
|
|
|
requests are received by the Friend node before the
|
|
|
|
PollTimeout timer expires, then the friendship is considered
|
2017-11-23 09:48:41 +02:00
|
|
|
terminated. The value is in units of 100 milliseconds, so e.g.
|
2018-02-01 09:51:36 -08:00
|
|
|
a value of 300 means 30 seconds.
|
2017-11-23 09:48:41 +02:00
|
|
|
|
|
|
|
config BT_MESH_LPN_INIT_POLL_TIMEOUT
|
|
|
|
int "The starting value of the PollTimeout timer"
|
|
|
|
range 10 BT_MESH_LPN_POLL_TIMEOUT
|
|
|
|
default BT_MESH_LPN_POLL_TIMEOUT
|
|
|
|
help
|
|
|
|
The initial value of the PollTimeout timer when Friendship
|
|
|
|
gets established for the first time. After this the timeout
|
|
|
|
will gradually grow toward the actual PollTimeout, doubling
|
|
|
|
in value for each iteration. The value is in units of 100
|
2017-12-07 15:19:28 +01:00
|
|
|
milliseconds, so e.g. a value of 300 means 30 seconds.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_LPN_SCAN_LATENCY
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Latency for enabling scanning"
|
|
|
|
range 0 50
|
|
|
|
default 10
|
|
|
|
help
|
|
|
|
Latency in milliseconds that it takes to enable scanning. This
|
|
|
|
is in practice how much time in advance before the Receive Window
|
|
|
|
that scanning is requested to be enabled.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_LPN_GROUPS
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Number of groups the LPN can subscribe to"
|
|
|
|
range 0 16384
|
|
|
|
default 8
|
|
|
|
help
|
|
|
|
Maximum number of groups that the LPN can subscribe to.
|
2020-08-10 10:55:21 +08:00
|
|
|
|
2020-08-26 10:13:45 +08:00
|
|
|
config BT_MESH_LPN_SUB_ALL_NODES_ADDR
|
|
|
|
bool "Automatically subscribe all nodes address"
|
|
|
|
help
|
|
|
|
Automatically subscribe all nodes address when friendship
|
|
|
|
established.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
endif # BT_MESH_LOW_POWER
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_FRIEND
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Support for acting as a Friend Node"
|
|
|
|
help
|
|
|
|
Enable this option to be able to act as a Friend Node.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
if BT_MESH_FRIEND
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2020-08-18 13:36:38 +02:00
|
|
|
config BT_MESH_FRIEND_ENABLED
|
|
|
|
bool "Friend feature enabled"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Controls whether the Friend feature is enabled by default. Can be
|
|
|
|
changed through runtime configuration.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_FRIEND_RECV_WIN
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Friend Receive Window"
|
|
|
|
range 1 255
|
|
|
|
default 255
|
|
|
|
help
|
|
|
|
Receive Window in milliseconds supported by the Friend node.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_FRIEND_QUEUE_SIZE
|
2017-10-31 16:16:28 +02:00
|
|
|
int "Minimum number of buffers supported per Friend Queue"
|
|
|
|
range 2 65536
|
2017-11-10 10:13:09 +02:00
|
|
|
default 16
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
2017-10-31 16:16:28 +02:00
|
|
|
Minimum number of buffers available to be stored for each
|
|
|
|
local Friend Queue.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_FRIEND_SUB_LIST_SIZE
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Friend Subscription List Size"
|
2017-10-31 16:16:28 +02:00
|
|
|
range 0 1023
|
|
|
|
default 3
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
Size of the Subscription List that can be supported by a
|
|
|
|
Friend node for a Low Power node.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_FRIEND_LPN_COUNT
|
2017-06-16 12:30:54 +03:00
|
|
|
int "Number of supported LPN nodes"
|
|
|
|
range 1 1000
|
2017-11-10 10:13:09 +02:00
|
|
|
default 2
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
Number of Low Power Nodes the Friend can have a Friendship
|
|
|
|
with simultaneously.
|
|
|
|
|
2017-10-31 16:16:28 +02:00
|
|
|
config BT_MESH_FRIEND_SEG_RX
|
|
|
|
int "Number of incomplete segment lists per LPN"
|
|
|
|
range 1 1000
|
|
|
|
default 1
|
|
|
|
help
|
|
|
|
Number of incomplete segment lists that we track for each LPN
|
|
|
|
that we are Friends for. In other words, this determines how
|
|
|
|
many elements we can simultaneously be receiving segmented
|
|
|
|
messages from when the messages are going into the Friend queue.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
endif # BT_MESH_FRIEND
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-11-12 13:48:55 +02:00
|
|
|
config BT_MESH_CFG_CLI
|
|
|
|
bool "Support for Configuration Client Model"
|
|
|
|
help
|
|
|
|
Enable support for the configuration client model.
|
|
|
|
|
2022-04-13 12:16:59 +02:00
|
|
|
if BT_MESH_CFG_CLI
|
|
|
|
|
|
|
|
config BT_MESH_CFG_CLI_TIMEOUT
|
|
|
|
int "Config Client model timeout in milliseconds"
|
|
|
|
default 5000
|
|
|
|
help
|
|
|
|
This timeout controls how long config client waits for a response
|
|
|
|
message to arrive. This value can be changed at runtime using
|
|
|
|
@ref bt_mesh_cfg_cli_timeout_set.
|
|
|
|
|
|
|
|
endif # BT_MESH_CFG_CLI
|
|
|
|
|
2017-11-22 08:49:52 +02:00
|
|
|
config BT_MESH_HEALTH_CLI
|
|
|
|
bool "Support for Health Client Model"
|
|
|
|
help
|
|
|
|
Enable support for the health client model.
|
|
|
|
|
2022-04-13 12:16:59 +02:00
|
|
|
if BT_MESH_HEALTH_CLI
|
|
|
|
|
|
|
|
config BT_MESH_HEALTH_CLI_TIMEOUT
|
|
|
|
int "Health Client model timeout in milliseconds"
|
|
|
|
default 2000
|
|
|
|
help
|
|
|
|
This timeout controls how long health client waits for a response
|
|
|
|
message to arrive. This value can be changed at runtime using
|
|
|
|
@ref bt_mesh_health_cli_timeout_set.
|
|
|
|
|
|
|
|
endif # BT_MESH_HEALTH_CLI
|
|
|
|
|
2017-11-10 22:17:40 +02:00
|
|
|
config BT_MESH_SHELL
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Bluetooth mesh shell"
|
2018-11-06 16:12:08 +02:00
|
|
|
select SHELL
|
2017-11-10 22:17:40 +02:00
|
|
|
help
|
2021-06-08 09:32:13 +02:00
|
|
|
Activate shell module that provides Bluetooth mesh commands to
|
2017-11-10 22:17:40 +02:00
|
|
|
the console.
|
|
|
|
|
2019-10-18 13:23:06 +02:00
|
|
|
config BT_MESH_MODEL_EXTENSIONS
|
|
|
|
bool "Support for Model extensions"
|
|
|
|
help
|
|
|
|
Enable support for the model extension concept, allowing the Access
|
2021-06-08 09:32:13 +02:00
|
|
|
layer to know about mesh model relationships.
|
2019-10-18 13:23:06 +02:00
|
|
|
|
2018-05-07 22:22:30 +03:00
|
|
|
if BT_SETTINGS
|
|
|
|
|
2018-05-08 23:34:56 +03:00
|
|
|
config BT_MESH_STORE_TIMEOUT
|
|
|
|
int "Delay (in seconds) before storing anything persistently"
|
|
|
|
range 0 1000000
|
|
|
|
default 2
|
|
|
|
help
|
|
|
|
This value defines in seconds how soon any pending changes
|
|
|
|
are actually written into persistent storage (flash) after
|
|
|
|
a change occurs.
|
|
|
|
|
2018-05-07 22:22:30 +03:00
|
|
|
config BT_MESH_SEQ_STORE_RATE
|
|
|
|
int "How often the sequence number gets updated in storage"
|
|
|
|
range 0 1000000
|
|
|
|
default 128
|
|
|
|
help
|
|
|
|
This value defines how often the local sequence number gets
|
|
|
|
updated in persistent storage (i.e. flash). E.g. a value of 100
|
|
|
|
means that the sequence number will be stored to flash on every
|
|
|
|
100th increment. If the node sends messages very frequently a
|
|
|
|
higher value makes more sense, whereas if the node sends
|
|
|
|
infrequently a value as low as 0 (update storage for every
|
|
|
|
increment) can make sense. When the stack gets initialized it
|
|
|
|
will add this number to the last stored one, so that it starts
|
|
|
|
off with a value that's guaranteed to be larger than the last
|
|
|
|
one used before power off.
|
|
|
|
|
|
|
|
config BT_MESH_RPL_STORE_TIMEOUT
|
2021-05-10 14:06:28 +02:00
|
|
|
int "Minimum interval after which unsaved RPL entries are updated in storage"
|
|
|
|
range -1 1000000
|
2018-05-07 22:22:30 +03:00
|
|
|
default 5
|
|
|
|
help
|
2021-05-10 14:06:28 +02:00
|
|
|
This value defines in seconds how soon unsaved RPL entries
|
|
|
|
gets written to the persistent storage. Setting this value
|
|
|
|
to a large number may lead to security vulnerabilities if a node
|
|
|
|
gets powered off before the timer is fired. When flash is used
|
|
|
|
as the persistent storage setting this value to a low number
|
|
|
|
may wear out flash sooner or later. However, if the RPL gets
|
|
|
|
updated infrequently a value as low as 0 (write immediately)
|
|
|
|
may make sense. Setting this value to -1 will disable this timer.
|
|
|
|
In this case, a user is responsible to store pending RPL entries
|
|
|
|
using @ref bt_mesh_rpl_pending_store. In the mean time, when
|
|
|
|
IV Index is updated, the outdated RPL entries will still be
|
|
|
|
stored by @ref BT_MESH_STORE_TIMEOUT. Finding the right balance
|
|
|
|
between this timeout and calling @ref bt_mesh_rpl_pending_store
|
|
|
|
may reduce a risk of security vulnerability and flash wear out.
|
2022-03-10 19:06:23 +01:00
|
|
|
Failure to store the RPL and becoming vulnerable after reboot
|
|
|
|
will cause the device to not perform the replay protection
|
|
|
|
required by the spec.
|
2018-05-07 22:22:30 +03:00
|
|
|
|
|
|
|
endif # BT_SETTINGS
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Debug logs"
|
2017-08-09 09:21:11 +03:00
|
|
|
depends on BT_DEBUG
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
Use this option to enable debug logs for the Bluetooth
|
|
|
|
Mesh functionality.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
if BT_MESH_DEBUG
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2018-03-21 09:24:25 +02:00
|
|
|
config BT_MESH_DEBUG_USE_ID_ADDR
|
|
|
|
bool "Use identity address for all advertising"
|
|
|
|
help
|
|
|
|
This option forces the usage of the local identity address for
|
|
|
|
all advertising. This can be a help for debugging (analyzing
|
|
|
|
traces), however it should never be enabled for a production
|
|
|
|
build as it compromises the privacy of the device.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_NET
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Network layer debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Network layer debug logs for the
|
2021-06-08 09:32:13 +02:00
|
|
|
Bluetooth mesh functionality.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2020-09-09 16:59:43 +08:00
|
|
|
config BT_MESH_DEBUG_RPL
|
|
|
|
bool "Replay protection list debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Replay protection list debug logs
|
2021-06-08 09:32:13 +02:00
|
|
|
for the Bluetooth mesh functionality.
|
2020-09-09 16:59:43 +08:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_TRANS
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Transport layer debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Transport layer debug logs for the
|
2021-06-08 09:32:13 +02:00
|
|
|
Bluetooth mesh functionality.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_BEACON
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Beacon debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Beacon-related debug logs for the
|
2021-06-08 09:32:13 +02:00
|
|
|
Bluetooth mesh functionality.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_CRYPTO
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Crypto debug"
|
|
|
|
help
|
|
|
|
Use this option to enable cryptographic debug logs for the
|
2021-06-08 09:32:13 +02:00
|
|
|
Bluetooth mesh functionality.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2020-08-25 11:03:42 +02:00
|
|
|
config BT_MESH_DEBUG_KEYS
|
|
|
|
bool "Key management debug"
|
|
|
|
help
|
|
|
|
Use this option to enable key management debug logs for the
|
2021-06-08 09:32:13 +02:00
|
|
|
Bluetooth mesh functionality.
|
2020-08-25 11:03:42 +02:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_PROV
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Provisioning debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Provisioning debug logs for the
|
2021-06-08 09:32:13 +02:00
|
|
|
Bluetooth mesh functionality.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2020-09-17 13:47:37 +08:00
|
|
|
config BT_MESH_DEBUG_PROVISIONER
|
|
|
|
bool "Provisioner debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Provisioner debug logs for the
|
2021-06-08 09:32:13 +02:00
|
|
|
Bluetooth mesh functionality.
|
2020-09-17 13:47:37 +08:00
|
|
|
|
2021-09-29 09:47:45 +02:00
|
|
|
config BT_MESH_DEBUG_PROV_DEVICE
|
|
|
|
bool "Provisioning device debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Provisioning device debug logs for the
|
|
|
|
Bluetooth Mesh functionality.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_ACCESS
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Access layer debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Access layer and device composition
|
2021-06-08 09:32:13 +02:00
|
|
|
related debug logs for Bluetooth mesh.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_MODEL
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Foundation model debug"
|
|
|
|
help
|
|
|
|
Use this option to enable debug logs for the Foundation
|
|
|
|
Models.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_ADV
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Advertising debug"
|
|
|
|
help
|
|
|
|
Use this option to enable advertising debug logs for
|
2021-06-08 09:32:13 +02:00
|
|
|
the Bluetooth mesh functionality.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_LOW_POWER
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Low Power debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Low Power debug logs for the
|
2021-06-08 09:32:13 +02:00
|
|
|
Bluetooth mesh functionality.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_FRIEND
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Friend debug"
|
|
|
|
help
|
|
|
|
Use this option to enable Friend debug logs for the
|
2021-06-08 09:32:13 +02:00
|
|
|
Bluetooth mesh functionality.
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MESH_DEBUG_PROXY
|
2017-06-16 12:30:54 +03:00
|
|
|
bool "Proxy debug"
|
2021-06-25 00:12:38 -07:00
|
|
|
depends on BT_MESH_GATT
|
2017-06-16 12:30:54 +03:00
|
|
|
help
|
|
|
|
Use this option to enable Proxy protocol debug logs.
|
|
|
|
|
2018-05-07 09:50:49 +03:00
|
|
|
config BT_MESH_DEBUG_SETTINGS
|
|
|
|
bool "Persistent settings debug"
|
|
|
|
depends on BT_SETTINGS
|
|
|
|
help
|
|
|
|
Use this option to enable persistent settings debug logs.
|
|
|
|
|
2019-11-04 16:14:07 +01:00
|
|
|
config BT_MESH_DEBUG_CDB
|
|
|
|
bool "Configuration database debug"
|
|
|
|
depends on BT_MESH_CDB
|
|
|
|
help
|
|
|
|
Use this option to enable configuration database debug logs.
|
|
|
|
|
2021-01-06 09:56:56 +01:00
|
|
|
config BT_MESH_DEBUG_CFG
|
|
|
|
bool "Configuration debug"
|
|
|
|
help
|
|
|
|
Use this option to enable node configuration debug logs for the
|
2021-06-08 09:32:13 +02:00
|
|
|
Bluetooth mesh functionality.
|
2021-01-06 09:56:56 +01:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
endif # BT_MESH_DEBUG
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
endif # BT_MESH
|