eca0141152
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>
707 lines
21 KiB
Text
707 lines
21 KiB
Text
# Bluetooth Mesh configuration options
|
|
|
|
# Copyright (c) 2017 Intel Corporation
|
|
# SPDX-License-Identifier: Apache-2.0
|
|
|
|
menuconfig BT_MESH
|
|
bool "Bluetooth Mesh support"
|
|
select TINYCRYPT
|
|
select TINYCRYPT_AES
|
|
select TINYCRYPT_AES_CMAC
|
|
select BT_HOST_CCM
|
|
depends on BT_OBSERVER && BT_BROADCASTER
|
|
help
|
|
This option enables Bluetooth Mesh support. The specific
|
|
features that are available may depend on other features
|
|
that have been enabled in the stack, such as GATT support.
|
|
|
|
if BT_MESH
|
|
|
|
# Virtual option enabled whenever Generic Provisioning layer is needed
|
|
config BT_MESH_PROV
|
|
bool
|
|
|
|
config BT_MESH_PB_ADV
|
|
bool "Provisioning support using the advertising bearer (PB-ADV)"
|
|
select BT_MESH_PROV
|
|
default y
|
|
help
|
|
Enable this option to allow the device to be provisioned over
|
|
the advertising bearer.
|
|
|
|
config BT_MESH_UNPROV_BEACON_INT
|
|
int
|
|
prompt "The interval (in seconds) to send the unprovisioned beacon" if BT_MESH_PB_ADV
|
|
default 5
|
|
range 1 10
|
|
help
|
|
This option specifies the interval (in seconds) at which the
|
|
device sends unprovisioned beacon.
|
|
|
|
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.
|
|
|
|
config BT_MESH_PROVISIONER
|
|
bool "Provisioner support"
|
|
select BT_MESH_PROV
|
|
help
|
|
Enable this option to have support for provisioning remote devices.
|
|
|
|
config BT_MESH_CDB
|
|
bool "Mesh Configuration Database [EXPERIMENTAL]"
|
|
|
|
if BT_MESH_CDB
|
|
|
|
config BT_MESH_CDB_NODE_COUNT
|
|
int "Maximum number of nodes in the database"
|
|
default 1
|
|
range 1 4096
|
|
help
|
|
This option specifies how many nodes each network can at most
|
|
save in the configuration database.
|
|
|
|
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
|
|
|
|
if BT_CONN
|
|
|
|
# Virtual option enabled whenever any Proxy protocol is needed
|
|
config BT_MESH_PROXY
|
|
bool
|
|
select BT_GATT_DYNAMIC_DB
|
|
|
|
config BT_MESH_PB_GATT
|
|
bool "Provisioning support using GATT (PB-GATT)"
|
|
select BT_MESH_PROXY
|
|
select BT_MESH_PROV
|
|
help
|
|
Enable this option to allow the device to be provisioned over
|
|
GATT.
|
|
|
|
config BT_MESH_GATT_PROXY
|
|
bool "GATT Proxy Service"
|
|
select BT_MESH_PROXY
|
|
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.
|
|
|
|
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.
|
|
|
|
config BT_MESH_PROXY_FILTER_SIZE
|
|
int "Maximum number of filter entries per Proxy Client"
|
|
default 3 if BT_MESH_GATT_PROXY
|
|
default 1
|
|
range 1 32767
|
|
depends on BT_MESH_PROXY
|
|
help
|
|
This option specifies how many Proxy Filter entries the local
|
|
node supports.
|
|
|
|
endif # BT_CONN
|
|
|
|
config BT_MESH_SELF_TEST
|
|
bool "Perform self-tests"
|
|
help
|
|
This option adds extra self-tests which are run every time
|
|
mesh networking is initialized.
|
|
|
|
config BT_MESH_IV_UPDATE_TEST
|
|
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.
|
|
|
|
config BT_MESH_SUBNET_COUNT
|
|
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.
|
|
|
|
config BT_MESH_APP_KEY_COUNT
|
|
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.
|
|
|
|
config BT_MESH_MODEL_KEY_COUNT
|
|
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.
|
|
|
|
config BT_MESH_MODEL_GROUP_COUNT
|
|
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.
|
|
|
|
config BT_MESH_LABEL_COUNT
|
|
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.
|
|
|
|
config BT_MESH_CRPL
|
|
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.
|
|
|
|
config BT_MESH_MSG_CACHE_SIZE
|
|
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.
|
|
|
|
config BT_MESH_ADV_BUF_COUNT
|
|
int "Number of advertising buffers"
|
|
default 6
|
|
range 1 256
|
|
help
|
|
Number of advertising buffers available. This should be chosen
|
|
based on what kind of features the local node should have. E.g.
|
|
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).
|
|
|
|
config BT_MESH_ADV_STACK_SIZE
|
|
int "Mesh advertiser thread stack size"
|
|
default 1024 if BT_HOST_CRYPTO
|
|
default 768
|
|
help
|
|
NOTE: This is an advanced setting and should not be changed unless
|
|
absolutely necessary
|
|
|
|
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).
|
|
|
|
In order to fulfill the above requirement, even if the node might
|
|
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).
|
|
|
|
config BT_MESH_TX_SEG_MSG_COUNT
|
|
int "Maximum number of simultaneous outgoing segmented messages"
|
|
default 1
|
|
range 1 255
|
|
help
|
|
Maximum number of simultaneous outgoing multi-segment and/or
|
|
reliable messages.
|
|
|
|
config BT_MESH_RX_SEG_MSG_COUNT
|
|
int "Maximum number of simultaneous incoming segmented messages"
|
|
default 1
|
|
range 1 255
|
|
help
|
|
Maximum number of simultaneous incoming multi-segment and/or
|
|
reliable messages.
|
|
|
|
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
|
|
help
|
|
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
|
|
range 2 32
|
|
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.
|
|
|
|
config BT_MESH_TX_SEG_MAX
|
|
int "Maximum number of segments in outgoing messages"
|
|
default 3
|
|
range 2 32
|
|
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.
|
|
This value affects memory consumption, which is why the
|
|
default is lower than the maximum that the specification
|
|
would allow (32 segments).
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
config BT_MESH_RELAY
|
|
bool "Relay support"
|
|
help
|
|
Support for acting as a Mesh Relay Node.
|
|
|
|
config BT_MESH_LOW_POWER
|
|
bool "Support for Low Power features"
|
|
help
|
|
Enable this option to be able to act as a Low Power Node.
|
|
|
|
if BT_MESH_LOW_POWER
|
|
|
|
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.
|
|
|
|
config BT_MESH_LPN_RSSI_FACTOR
|
|
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.
|
|
|
|
config BT_MESH_LPN_RECV_WIN_FACTOR
|
|
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.
|
|
|
|
config BT_MESH_LPN_MIN_QUEUE_SIZE
|
|
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.
|
|
|
|
config BT_MESH_LPN_RECV_DELAY
|
|
int "Receive delay requested by the local node"
|
|
range 10 255
|
|
default 100
|
|
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.
|
|
|
|
config BT_MESH_LPN_POLL_TIMEOUT
|
|
int "The value of the PollTimeout timer"
|
|
range 10 244735
|
|
default 300
|
|
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
|
|
terminated. The value is in units of 100 milliseconds, so e.g.
|
|
a value of 300 means 30 seconds.
|
|
|
|
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
|
|
milliseconds, so e.g. a value of 300 means 30 seconds.
|
|
|
|
config BT_MESH_LPN_SCAN_LATENCY
|
|
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.
|
|
|
|
config BT_MESH_LPN_GROUPS
|
|
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.
|
|
|
|
config BT_MESH_LPN_SUB_ALL_NODES_ADDR
|
|
bool "Automatically subscribe all nodes address"
|
|
help
|
|
Automatically subscribe all nodes address when friendship
|
|
established.
|
|
|
|
endif # BT_MESH_LOW_POWER
|
|
|
|
config BT_MESH_FRIEND
|
|
bool "Support for acting as a Friend Node"
|
|
help
|
|
Enable this option to be able to act as a Friend Node.
|
|
|
|
if BT_MESH_FRIEND
|
|
|
|
config BT_MESH_FRIEND_RECV_WIN
|
|
int "Friend Receive Window"
|
|
range 1 255
|
|
default 255
|
|
help
|
|
Receive Window in milliseconds supported by the Friend node.
|
|
|
|
config BT_MESH_FRIEND_QUEUE_SIZE
|
|
int "Minimum number of buffers supported per Friend Queue"
|
|
range 2 65536
|
|
default 16
|
|
help
|
|
Minimum number of buffers available to be stored for each
|
|
local Friend Queue.
|
|
|
|
config BT_MESH_FRIEND_SUB_LIST_SIZE
|
|
int "Friend Subscription List Size"
|
|
range 0 1023
|
|
default 3
|
|
help
|
|
Size of the Subscription List that can be supported by a
|
|
Friend node for a Low Power node.
|
|
|
|
config BT_MESH_FRIEND_LPN_COUNT
|
|
int "Number of supported LPN nodes"
|
|
range 1 1000
|
|
default 2
|
|
help
|
|
Number of Low Power Nodes the Friend can have a Friendship
|
|
with simultaneously.
|
|
|
|
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.
|
|
|
|
endif # BT_MESH_FRIEND
|
|
|
|
config BT_MESH_CFG_CLI
|
|
bool "Support for Configuration Client Model"
|
|
help
|
|
Enable support for the configuration client model.
|
|
|
|
config BT_MESH_HEALTH_CLI
|
|
bool "Support for Health Client Model"
|
|
help
|
|
Enable support for the health client model.
|
|
|
|
config BT_MESH_SHELL
|
|
bool "Enable Bluetooth Mesh shell"
|
|
select SHELL
|
|
depends on BT_MESH_CFG_CLI
|
|
depends on BT_MESH_HEALTH_CLI
|
|
help
|
|
Activate shell module that provides Bluetooth Mesh commands to
|
|
the console.
|
|
|
|
config BT_MESH_MODEL_EXTENSIONS
|
|
bool "Support for Model extensions"
|
|
help
|
|
Enable support for the model extension concept, allowing the Access
|
|
layer to know about Mesh model relationships.
|
|
|
|
if BT_SETTINGS
|
|
|
|
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.
|
|
|
|
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
|
|
int "Minimum frequency that the RPL gets updated in storage"
|
|
range 0 1000000
|
|
default 5
|
|
help
|
|
This value defines in seconds how soon the RPL gets written to
|
|
persistent storage after a change occurs. If the node receives
|
|
messages frequently it may make sense to have this set to a
|
|
large value, whereas if the RPL gets updated infrequently a
|
|
value as low as 0 (write immediately) may make sense. Note that
|
|
if the node operates a security sensitive use case, and there's
|
|
a risk of sudden power loss, it may be a security vulnerability
|
|
to set this value to anything else than 0 (a power loss before
|
|
writing to storage exposes the node to potential message
|
|
replay attacks).
|
|
|
|
endif # BT_SETTINGS
|
|
|
|
config BT_MESH_DEBUG
|
|
bool "Enable debug logs"
|
|
depends on BT_DEBUG
|
|
help
|
|
Use this option to enable debug logs for the Bluetooth
|
|
Mesh functionality.
|
|
|
|
if BT_MESH_DEBUG
|
|
|
|
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.
|
|
|
|
config BT_MESH_DEBUG_NET
|
|
bool "Network layer debug"
|
|
help
|
|
Use this option to enable Network layer debug logs for the
|
|
Bluetooth Mesh functionality.
|
|
|
|
config BT_MESH_DEBUG_RPL
|
|
bool "Replay protection list debug"
|
|
help
|
|
Use this option to enable Replay protection list debug logs
|
|
for the Bluetooth Mesh functionality.
|
|
|
|
config BT_MESH_DEBUG_TRANS
|
|
bool "Transport layer debug"
|
|
help
|
|
Use this option to enable Transport layer debug logs for the
|
|
Bluetooth Mesh functionality.
|
|
|
|
config BT_MESH_DEBUG_BEACON
|
|
bool "Beacon debug"
|
|
help
|
|
Use this option to enable Beacon-related debug logs for the
|
|
Bluetooth Mesh functionality.
|
|
|
|
config BT_MESH_DEBUG_CRYPTO
|
|
bool "Crypto debug"
|
|
help
|
|
Use this option to enable cryptographic debug logs for the
|
|
Bluetooth Mesh functionality.
|
|
|
|
config BT_MESH_DEBUG_KEYS
|
|
bool "Key management debug"
|
|
help
|
|
Use this option to enable key management debug logs for the
|
|
Bluetooth Mesh functionality.
|
|
|
|
config BT_MESH_DEBUG_PROV
|
|
bool "Provisioning debug"
|
|
help
|
|
Use this option to enable Provisioning debug logs for the
|
|
Bluetooth Mesh functionality.
|
|
|
|
config BT_MESH_DEBUG_ACCESS
|
|
bool "Access layer debug"
|
|
help
|
|
Use this option to enable Access layer and device composition
|
|
related debug logs for Bluetooth Mesh.
|
|
|
|
config BT_MESH_DEBUG_MODEL
|
|
bool "Foundation model debug"
|
|
help
|
|
Use this option to enable debug logs for the Foundation
|
|
Models.
|
|
|
|
config BT_MESH_DEBUG_ADV
|
|
bool "Advertising debug"
|
|
help
|
|
Use this option to enable advertising debug logs for
|
|
the Bluetooth Mesh functionality.
|
|
|
|
config BT_MESH_DEBUG_LOW_POWER
|
|
bool "Low Power debug"
|
|
help
|
|
Use this option to enable Low Power debug logs for the
|
|
Bluetooth Mesh functionality.
|
|
|
|
config BT_MESH_DEBUG_FRIEND
|
|
bool "Friend debug"
|
|
help
|
|
Use this option to enable Friend debug logs for the
|
|
Bluetooth Mesh functionality.
|
|
|
|
config BT_MESH_DEBUG_PROXY
|
|
bool "Proxy debug"
|
|
depends on BT_MESH_PROXY
|
|
help
|
|
Use this option to enable Proxy protocol debug logs.
|
|
|
|
config BT_MESH_DEBUG_SETTINGS
|
|
bool "Persistent settings debug"
|
|
depends on BT_SETTINGS
|
|
help
|
|
Use this option to enable persistent settings debug logs.
|
|
|
|
config BT_MESH_DEBUG_CDB
|
|
bool "Configuration database debug"
|
|
depends on BT_MESH_CDB
|
|
help
|
|
Use this option to enable configuration database debug logs.
|
|
|
|
endif # BT_MESH_DEBUG
|
|
|
|
endif # BT_MESH
|