2019-11-01 13:45:29 +01:00
|
|
|
# Bluetooth LE stack configuration options
|
2015-05-20 11:40:39 -05:00
|
|
|
|
2020-01-29 13:03:23 +01:00
|
|
|
# Copyright (c) 2016-2020 Nordic Semiconductor ASA
|
2016-06-10 12:10:18 +03:00
|
|
|
# Copyright (c) 2015-2016 Intel Corporation
|
2017-01-18 17:01:01 -08:00
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
2015-05-15 18:46:02 -04:00
|
|
|
|
2022-05-30 16:08:11 +02:00
|
|
|
config BT_LONG_WQ
|
|
|
|
bool "Dedicated workqueue for long-running tasks."
|
|
|
|
default y if BT_GATT_CACHING
|
|
|
|
help
|
|
|
|
Adds an API for a workqueue dedicated to long-running tasks.
|
|
|
|
|
|
|
|
if BT_LONG_WQ
|
|
|
|
config BT_LONG_WQ_STACK_SIZE
|
|
|
|
# Hidden: Long workqueue stack size. Should be derived from system
|
|
|
|
# requirements.
|
|
|
|
int
|
2022-08-10 13:48:55 +02:00
|
|
|
default 1300 if BT_GATT_CACHING
|
|
|
|
default 1140 if BT_TINYCRYPT_ECC
|
2022-05-30 16:08:11 +02:00
|
|
|
default 1024
|
|
|
|
|
|
|
|
config BT_LONG_WQ_PRIO
|
|
|
|
int "Long workqueue priority. Should be pre-emptible."
|
|
|
|
default 10
|
|
|
|
range 0 NUM_PREEMPT_PRIORITIES
|
2023-09-08 14:57:48 +01:00
|
|
|
|
|
|
|
config BT_LONG_WQ_INIT_PRIO
|
|
|
|
int "Long workqueue init priority"
|
|
|
|
default 50
|
|
|
|
help
|
|
|
|
Init priority level to setup the long workqueue.
|
|
|
|
|
2022-05-30 16:08:11 +02:00
|
|
|
endif # BT_LONG_WQ
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_HCI_HOST
|
2019-10-17 16:53:06 +02:00
|
|
|
# Hidden option to make the conditions more intuitive
|
2016-11-09 12:23:21 +02:00
|
|
|
bool
|
2016-08-10 16:51:20 +03:00
|
|
|
default y
|
2017-08-09 09:21:11 +03:00
|
|
|
depends on !BT_HCI_RAW
|
2017-02-02 08:24:28 +02:00
|
|
|
select POLL
|
2016-02-09 11:17:02 +01:00
|
|
|
|
2020-01-10 09:30:34 +01:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_HCI_TX_STACK_SIZE
|
2019-08-20 08:53:01 +02:00
|
|
|
# NOTE: This value is derived from other symbols and should only be
|
|
|
|
# changed if required by architecture
|
cmake: make the BT_HCI_TX_STACK_SIZE's prompt conditional
The BT_HCI_TX_STACK_SIZE is carefully calculated from other
options. When those options change, e.g. from a menuconfig update, it
is important that the stack size is re-calculated, but it is not when
there is a prompt.
Therefore, make the prompt conditional such that the previously set
value is only used when it has been explicitly configured to be so.
Now users can still change the value through menuconfig and prj.conf,
by also enabling <option>_WITH_PROMPT, but when the value is
calculated by the defaults, it will continue to be calculated by
defaults instead of inheriting the intial value.
This is AFAIK a novel approach, but testing has shown that it gives
the users the behaviour they want, at the cost of some boilerplate of
course. This pattern can be applied to other options if it proves to
work as intended.
Alternatively one could remove the prompt, but then it would no longer
be possible to override the value through menuconfig.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-11-14 15:33:44 +01:00
|
|
|
int
|
|
|
|
prompt "HCI Tx thread stack size" if BT_HCI_TX_STACK_SIZE_WITH_PROMPT
|
2019-01-15 08:28:41 +02:00
|
|
|
default 512 if BT_H4
|
|
|
|
default 512 if BT_H5
|
2017-08-16 10:56:28 +03:00
|
|
|
default 416 if BT_SPI
|
2024-04-03 13:46:16 +02:00
|
|
|
default 1152 if BT_CTLR && BT_LL_SW_SPLIT && (NO_OPTIMIZATIONS || BT_ISO_BROADCAST)
|
2020-05-06 10:53:05 +02:00
|
|
|
default 1024 if BT_CTLR && BT_LL_SW_SPLIT && BT_CENTRAL
|
2022-04-21 13:32:08 +02:00
|
|
|
default 768 if BT_CTLR && BT_LL_SW_SPLIT
|
2019-01-15 08:28:41 +02:00
|
|
|
default 512 if BT_USERCHAN
|
2019-02-27 14:19:25 +01:00
|
|
|
default 640 if BT_STM32_IPM
|
Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
|
|
|
# Even if no driver is selected the following default is still
|
2019-02-21 16:09:25 +01:00
|
|
|
# needed e.g. for unit tests. This default will also server as
|
|
|
|
# the worst-case stack size if an out-of-tree controller is used.
|
|
|
|
default 1024
|
Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
|
|
|
help
|
2019-08-20 08:53:01 +02:00
|
|
|
Stack size needed for executing bt_send with specified driver.
|
|
|
|
NOTE: This is an advanced setting and should not be changed unless
|
2021-02-24 08:31:15 -06:00
|
|
|
absolutely necessary. To change this you must first select
|
|
|
|
BT_HCI_TX_STACK_SIZE_WITH_PROMPT.
|
2019-08-20 08:53:01 +02:00
|
|
|
|
cmake: make the BT_HCI_TX_STACK_SIZE's prompt conditional
The BT_HCI_TX_STACK_SIZE is carefully calculated from other
options. When those options change, e.g. from a menuconfig update, it
is important that the stack size is re-calculated, but it is not when
there is a prompt.
Therefore, make the prompt conditional such that the previously set
value is only used when it has been explicitly configured to be so.
Now users can still change the value through menuconfig and prj.conf,
by also enabling <option>_WITH_PROMPT, but when the value is
calculated by the defaults, it will continue to be calculated by
defaults instead of inheriting the intial value.
This is AFAIK a novel approach, but testing has shown that it gives
the users the behaviour they want, at the cost of some boilerplate of
course. This pattern can be applied to other options if it proves to
work as intended.
Alternatively one could remove the prompt, but then it would no longer
be possible to override the value through menuconfig.
Signed-off-by: Sebastian Bøe <sebastian.boe@nordicsemi.no>
2019-11-14 15:33:44 +01:00
|
|
|
config BT_HCI_TX_STACK_SIZE_WITH_PROMPT
|
|
|
|
bool "Override HCI Tx thread stack size"
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_HCI_TX_PRIO
|
2017-07-11 09:47:08 +02:00
|
|
|
# Hidden option for Co-Operative Tx thread priority
|
|
|
|
int
|
|
|
|
default 7
|
|
|
|
|
2022-03-11 11:12:59 +08:00
|
|
|
choice BT_RECV_CONTEXT
|
|
|
|
prompt "BT RX Thread Selection"
|
2024-03-20 14:44:07 +01:00
|
|
|
default BT_RECV_WORKQ_SYS if SOC_SERIES_NRF51X
|
2022-03-11 11:12:59 +08:00
|
|
|
default BT_RECV_WORKQ_BT
|
|
|
|
help
|
|
|
|
Selects in which context incoming low priority HCI packets are processed.
|
|
|
|
The host defines some events as high priority to avoid race conditions and deadlocks.
|
|
|
|
High priority events are always processed in the context of the caller of bt_recv()
|
|
|
|
or bt_recv_prio(). The choice will influence RAM usage and how fast incoming HCI
|
|
|
|
packets are processed.
|
|
|
|
|
|
|
|
config BT_RECV_WORKQ_SYS
|
|
|
|
bool "Process low priority HCI packets in the system work queue"
|
|
|
|
help
|
|
|
|
When this option is selected, the host will process incoming low priority HCI packets
|
|
|
|
in the system work queue. The HCI driver shall not call bt_recv_prio().
|
|
|
|
High priority HCI packets will processed in the context of the caller of bt_recv().
|
|
|
|
The application needs to ensure the system workqueue stack size (SYSTEM_WORKQUEUE_STACK_SIZE)
|
|
|
|
is large enough, refer to BT_RX_STACK_SIZE for the recommended minimum.
|
|
|
|
Note: When this option is used, other users of the system work queue will influence the
|
|
|
|
latency of incoming Bluetooth events.
|
|
|
|
|
|
|
|
config BT_RECV_WORKQ_BT
|
|
|
|
bool "Process low priority HCI packets in the bluetooth-specific work queue"
|
|
|
|
help
|
|
|
|
When this option is selected, the host will process incoming low priority HCI packets
|
|
|
|
in the bluetooth-specific work queue. The HCI driver shall not call bt_recv_prio().
|
|
|
|
High priority HCI packets will processed in the context of the caller of bt_recv().
|
|
|
|
The application needs to ensure the bluetooth-specific work queue size is large enough,
|
|
|
|
refer to BT_RX_STACK_SIZE for the recommended minimum.
|
|
|
|
endchoice
|
2017-03-31 08:38:55 +02:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_RX_STACK_SIZE
|
2016-11-10 22:01:50 +02:00
|
|
|
int "Size of the receiving thread stack"
|
2022-03-26 08:05:14 +01:00
|
|
|
default 768 if BT_HCI_RAW
|
2022-02-07 17:13:02 +08:00
|
|
|
default 3092 if BT_MESH_GATT_CLIENT
|
2021-08-09 16:43:16 +02:00
|
|
|
default 2600 if BT_MESH
|
2022-02-17 12:27:36 +01:00
|
|
|
default 2048 if BT_AUDIO
|
2018-10-08 14:33:40 +02:00
|
|
|
default 2200 if BT_SETTINGS
|
2022-08-25 15:13:00 +02:00
|
|
|
default 1200
|
2016-02-12 12:59:55 +02:00
|
|
|
help
|
2016-11-10 22:01:50 +02:00
|
|
|
Size of the receiving thread stack. This is the context from
|
2016-02-12 12:59:55 +02:00
|
|
|
which all event callbacks to the application occur. The
|
|
|
|
default value is sufficient for basic operation, but if the
|
|
|
|
application needs to do advanced things in its callbacks that
|
|
|
|
require extra stack space, this value can be increased to
|
2016-10-05 10:00:41 -05:00
|
|
|
accommodate for that.
|
2016-02-12 12:59:55 +02:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_RX_PRIO
|
2017-07-11 09:47:08 +02:00
|
|
|
# Hidden option for Co-Operative Rx thread priority
|
|
|
|
int
|
|
|
|
default 8
|
|
|
|
|
2020-08-19 17:16:01 +02:00
|
|
|
config BT_DRIVER_RX_HIGH_PRIO
|
|
|
|
# Hidden option for Co-Operative HCI driver RX thread priority
|
|
|
|
int
|
|
|
|
default 6
|
|
|
|
|
2022-02-16 10:30:00 +01:00
|
|
|
menu "Bluetooth Host"
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
if BT_HCI_HOST
|
2017-06-16 12:30:54 +03:00
|
|
|
|
2022-02-16 16:57:09 +01:00
|
|
|
rsource "../mesh/Kconfig"
|
|
|
|
rsource "../audio/Kconfig"
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_HOST_CRYPTO
|
2023-11-01 15:44:23 +01:00
|
|
|
bool "Use crypto functionality implemented in the Bluetooth host"
|
2018-06-26 11:51:18 +02:00
|
|
|
default y if !BT_CTLR_CRYPTO
|
2017-03-15 11:19:27 +01:00
|
|
|
select TINYCRYPT
|
|
|
|
select TINYCRYPT_AES
|
2023-11-01 15:44:23 +01:00
|
|
|
help
|
|
|
|
The option adds the AES encryption support using TinyCrypt
|
|
|
|
library if this is not provided by the controller implementation.
|
2022-01-29 08:53:38 +08:00
|
|
|
|
|
|
|
config BT_HOST_CRYPTO_PRNG
|
|
|
|
bool "Use Tinycrypt library for random number generation"
|
|
|
|
default y
|
2017-03-15 11:19:27 +01:00
|
|
|
select TINYCRYPT_SHA256
|
|
|
|
select TINYCRYPT_SHA256_HMAC
|
|
|
|
select TINYCRYPT_SHA256_HMAC_PRNG
|
2022-01-29 08:53:38 +08:00
|
|
|
depends on BT_HOST_CRYPTO
|
|
|
|
help
|
|
|
|
When selected, will use tinycrypt library for random number generation.
|
|
|
|
This will consume additional ram, but may speed up the generation of random
|
|
|
|
numbers.
|
|
|
|
|
|
|
|
Otherwise, random numbers will be generated through multiple HCI calls,
|
|
|
|
which will not consume additional resources, but may take a long time,
|
|
|
|
depending on the length of the random data.
|
|
|
|
This method is generally recommended within 16 bytes.
|
2017-03-15 11:19:27 +01:00
|
|
|
|
2018-04-26 22:05:26 +03:00
|
|
|
config BT_SETTINGS
|
|
|
|
bool "Store Bluetooth state and configuration persistently"
|
2019-09-13 14:06:22 +02:00
|
|
|
depends on SETTINGS
|
2018-04-26 22:05:26 +03:00
|
|
|
select MPU_ALLOW_FLASH_WRITE if ARM_MPU
|
|
|
|
help
|
|
|
|
When selected, the Bluetooth stack will take care of storing
|
|
|
|
(and restoring) the Bluetooth state (e.g. pairing keys) and
|
|
|
|
configuration persistently in flash.
|
|
|
|
|
|
|
|
When this option has been enabled, it's important that the
|
|
|
|
application makes a call to settings_load() after having done
|
|
|
|
all necessary initialization (e.g. calling bt_enable). The
|
|
|
|
reason settings_load() is handled externally to the stack, is
|
|
|
|
that there may be other subsystems using the settings API, in
|
|
|
|
which case it's more efficient to load all settings in one go,
|
|
|
|
instead of each subsystem doing it independently.
|
|
|
|
|
2023-09-25 16:19:10 +02:00
|
|
|
Warning: The Bluetooth host expects a settings backend that loads
|
|
|
|
settings items in handle order.
|
|
|
|
|
2018-10-08 14:33:40 +02:00
|
|
|
if BT_SETTINGS
|
2019-11-05 08:20:07 +01:00
|
|
|
config BT_SETTINGS_CCC_LAZY_LOADING
|
|
|
|
bool "Load CCC values from settings when peer connects"
|
2021-04-07 09:27:25 +02:00
|
|
|
depends on BT_CONN
|
2019-11-05 08:20:07 +01:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
Load Client Configuration Characteristic setting right after a bonded
|
|
|
|
device connects.
|
|
|
|
Disabling this option will increase memory usage as CCC values for all
|
|
|
|
bonded devices will be loaded when calling settings_load.
|
|
|
|
|
2023-01-30 13:43:11 +01:00
|
|
|
config BT_SETTINGS_DELAYED_STORE
|
|
|
|
# Enables delayed non-volatile storage mechanism
|
|
|
|
bool
|
|
|
|
help
|
|
|
|
Triggers the storage of the CF and CCC right after a write.
|
|
|
|
This is done in the workqueue context, in order to not block the BT RX
|
|
|
|
thread for too long.
|
|
|
|
|
|
|
|
config BT_SETTINGS_DELAYED_STORE_MS
|
|
|
|
int
|
|
|
|
default 1000
|
|
|
|
help
|
|
|
|
(Advanced) Governs the timeout after which the settings write will
|
|
|
|
take effect.
|
|
|
|
|
2018-10-08 14:33:40 +02:00
|
|
|
config BT_SETTINGS_CCC_STORE_ON_WRITE
|
|
|
|
bool "Store CCC value immediately after it has been written"
|
2021-04-07 09:27:25 +02:00
|
|
|
depends on BT_CONN
|
2023-01-30 13:43:11 +01:00
|
|
|
select BT_SETTINGS_DELAYED_STORE
|
2021-11-30 09:18:32 +01:00
|
|
|
default y
|
2018-10-08 14:33:40 +02:00
|
|
|
help
|
|
|
|
Store Client Configuration Characteristic value right after it has
|
2021-11-30 09:18:32 +01:00
|
|
|
been updated. If the option is disabled, the CCC is only stored on
|
|
|
|
disconnection.
|
2019-09-13 14:06:22 +02:00
|
|
|
|
2023-01-30 13:43:11 +01:00
|
|
|
config BT_SETTINGS_CF_STORE_ON_WRITE
|
|
|
|
bool "Store CF value immediately after it has been written"
|
|
|
|
depends on BT_CONN && BT_GATT_CACHING
|
|
|
|
select BT_SETTINGS_DELAYED_STORE
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Store Client Supported Features value right after it has been updated.
|
|
|
|
If the option is disabled, the CF is only stored on disconnection.
|
|
|
|
|
2019-09-13 14:06:22 +02:00
|
|
|
config BT_SETTINGS_USE_PRINTK
|
|
|
|
bool "Use snprintk to encode Bluetooth settings key strings"
|
|
|
|
depends on SETTINGS && PRINTK
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
When selected, Bluetooth settings will use snprintk to encode
|
|
|
|
key strings.
|
|
|
|
When not selected, Bluetooth settings will use a faster builtin
|
|
|
|
function to encode the key string. The drawback is that if
|
|
|
|
printk is enabled then the program memory footprint will be larger.
|
2018-10-08 14:33:40 +02:00
|
|
|
endif # BT_SETTINGS
|
|
|
|
|
2021-09-14 12:28:45 +02:00
|
|
|
config BT_FILTER_ACCEPT_LIST
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Filter accept list support"
|
2019-07-22 13:13:38 +02:00
|
|
|
help
|
2022-03-16 21:07:43 +00:00
|
|
|
This option enables the filter accept list API. This takes advantage of the
|
2021-09-14 12:28:45 +02:00
|
|
|
filtering feature of a BLE controller.
|
|
|
|
The filter accept list is a global list and the same list is used
|
|
|
|
by both scanner and advertiser. The filter accept list cannot be modified while
|
2019-07-22 13:13:38 +02:00
|
|
|
it is in use.
|
|
|
|
|
2021-09-14 12:28:45 +02:00
|
|
|
An Advertiser can filter which peers can connect or request scan
|
2019-07-22 13:13:38 +02:00
|
|
|
response data.
|
2021-09-14 12:28:45 +02:00
|
|
|
A scanner can filter advertisers for which it will generate
|
2019-07-22 13:13:38 +02:00
|
|
|
advertising reports.
|
2021-09-14 12:28:45 +02:00
|
|
|
Connections can be established automatically for accepted peers.
|
2019-07-22 13:13:38 +02:00
|
|
|
|
2022-02-16 10:53:30 +01:00
|
|
|
config BT_LIM_ADV_TIMEOUT
|
|
|
|
int "Timeout for limited advertising in 1s units"
|
|
|
|
default 30
|
|
|
|
range 1 180
|
|
|
|
depends on BT_BROADCASTER
|
|
|
|
help
|
|
|
|
After this timeout is reached, advertisement with BT_LE_AD_LIMITED flag
|
|
|
|
set shall be terminated. As per BT Core Spec 5.2, Vol 3, Part C,
|
|
|
|
Appendix A (NORMATIVE): TIMERS AND CONSTANTS it's required to be no more
|
|
|
|
than 180s.
|
|
|
|
|
2023-02-17 08:55:41 +01:00
|
|
|
config BT_CONN_TX_USER_DATA_SIZE
|
|
|
|
int
|
2023-07-14 16:29:13 +02:00
|
|
|
default 24 if 64BIT
|
|
|
|
default 12
|
2023-02-17 08:55:41 +01:00
|
|
|
help
|
|
|
|
Necessary user_data size for allowing packet fragmentation when
|
|
|
|
sending over HCI. See `struct tx_meta` in conn.c.
|
|
|
|
|
2023-07-18 10:39:44 +02:00
|
|
|
config BT_CONN_FRAG_COUNT
|
|
|
|
int
|
|
|
|
default BT_MAX_CONN if BT_CONN
|
|
|
|
default BT_ISO_MAX_CHAN if BT_ISO
|
|
|
|
help
|
|
|
|
Internal kconfig that sets the maximum amount of simultaneous data
|
|
|
|
packets in flight. It should be equal to the number of connections.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
if BT_CONN
|
2017-05-04 14:09:10 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_CONN_TX_MAX
|
2019-11-23 00:08:46 +02:00
|
|
|
int "Maximum number of pending TX buffers with a callback"
|
|
|
|
default BT_L2CAP_TX_BUF_COUNT
|
|
|
|
range BT_L2CAP_TX_BUF_COUNT 255
|
2017-03-17 08:02:57 +02:00
|
|
|
help
|
2019-11-23 00:08:46 +02:00
|
|
|
Maximum number of pending TX buffers that have an associated
|
|
|
|
callback. Normally this can be left to the default value, which
|
|
|
|
is equal to the number of TX buffers in the stack-internal pool.
|
2017-03-17 08:02:57 +02:00
|
|
|
|
2023-07-13 18:51:53 +02:00
|
|
|
config BT_CONN_PARAM_ANY
|
|
|
|
bool "Accept any values for connection parameters"
|
|
|
|
help
|
|
|
|
Some controllers support additional connection parameter ranges
|
|
|
|
beyond what is described in the specification. Enabling this option
|
|
|
|
allows the application to set any value to all connection parameters.
|
|
|
|
Tbe Host will perform no limits nor consistency checks on any of the
|
|
|
|
connection parameters (conn interval min and max, latency and timeout).
|
|
|
|
However, the Host will still use numerical comparisons between the
|
|
|
|
min and max connection intervals in order to verify whether the
|
|
|
|
desired parameters have been established in the connection.
|
|
|
|
|
2020-04-22 20:37:55 +02:00
|
|
|
config BT_USER_PHY_UPDATE
|
|
|
|
bool "User control of PHY Update Procedure"
|
|
|
|
depends on BT_PHY_UPDATE
|
|
|
|
help
|
|
|
|
Enable application access to initiate the PHY Update Procedure.
|
|
|
|
The application can also register a callback to be notified about PHY
|
|
|
|
changes on the connection. The current PHY info is available in the
|
|
|
|
connection info.
|
|
|
|
|
2018-08-27 07:45:43 +02:00
|
|
|
config BT_AUTO_PHY_UPDATE
|
|
|
|
bool "Auto-initiate PHY Update Procedure"
|
2018-11-21 10:52:18 +01:00
|
|
|
depends on BT_PHY_UPDATE
|
2020-04-22 20:37:55 +02:00
|
|
|
default y if !BT_USER_PHY_UPDATE
|
2018-08-27 07:45:43 +02:00
|
|
|
help
|
|
|
|
Initiate PHY Update Procedure on connection establishment.
|
|
|
|
|
2020-04-22 20:19:15 +02:00
|
|
|
Disable this if you want the PHY Update Procedure feature supported
|
|
|
|
but want to rely on the remote device to initiate the procedure at its
|
2020-04-22 20:37:55 +02:00
|
|
|
discretion or want to initiate manually.
|
2018-08-27 07:45:43 +02:00
|
|
|
|
2020-04-22 20:28:48 +02:00
|
|
|
config BT_USER_DATA_LEN_UPDATE
|
|
|
|
bool "User control of Data Length Update Procedure"
|
|
|
|
depends on BT_DATA_LEN_UPDATE
|
|
|
|
help
|
|
|
|
Enable application access to initiate the Data Length Update
|
|
|
|
Procedure. The application can also a register callback to be notified
|
|
|
|
about Data Length changes on the connection. The current Data Length
|
|
|
|
info is available in the connection info.
|
|
|
|
|
2020-04-22 20:19:15 +02:00
|
|
|
config BT_AUTO_DATA_LEN_UPDATE
|
|
|
|
bool "Auto-initiate Data Length Update procedure"
|
|
|
|
depends on BT_DATA_LEN_UPDATE
|
2020-04-22 20:28:48 +02:00
|
|
|
default y if !BT_USER_DATA_LEN_UPDATE
|
2020-04-22 20:19:15 +02:00
|
|
|
help
|
|
|
|
Initiate Data Length Update Procedure on connection establishment.
|
|
|
|
|
|
|
|
Disable this if you want the Data Length Update Procedure feature
|
|
|
|
supported but want to rely on the remote device to initiate the
|
2020-04-22 20:28:48 +02:00
|
|
|
procedure at its discretion or want to initiate manually.
|
2020-04-22 20:19:15 +02:00
|
|
|
|
2019-09-27 14:53:40 +02:00
|
|
|
config BT_REMOTE_INFO
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Application access to remote information"
|
2019-09-27 14:53:40 +02:00
|
|
|
help
|
|
|
|
Enable application access to the remote information available in the
|
|
|
|
stack. The remote information is retrieved once a connection has been
|
|
|
|
established and the application will be notified when this information
|
2021-12-21 15:45:01 +01:00
|
|
|
is available through the remote_info_available connection callback.
|
2019-09-27 14:53:40 +02:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_SMP
|
2015-10-29 13:59:54 +02:00
|
|
|
bool "Security Manager Protocol support"
|
2022-10-31 14:58:02 +01:00
|
|
|
select BT_CRYPTO
|
2017-08-09 09:21:11 +03:00
|
|
|
select BT_RPA
|
2020-12-10 12:24:41 +01:00
|
|
|
select BT_ECC
|
2015-11-06 22:22:33 +02:00
|
|
|
help
|
|
|
|
This option enables support for the Security Manager Protocol
|
|
|
|
(SMP), making it possible to pair devices over LE.
|
2015-09-09 17:27:16 +02:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
if BT_SMP
|
2023-01-10 21:56:09 +01:00
|
|
|
config BT_PASSKEY_KEYPRESS
|
|
|
|
bool "Passkey Keypress Notification support [EXPERIMENTAL]"
|
|
|
|
select EXPERIMENTAL
|
|
|
|
help
|
|
|
|
Enable support for receiving and sending Keypress Notifications during
|
|
|
|
Passkey Entry during pairing.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_PRIVACY
|
2023-05-22 09:10:36 +02:00
|
|
|
bool "Device privacy"
|
2016-04-04 12:55:11 +03:00
|
|
|
help
|
2023-05-22 09:10:36 +02:00
|
|
|
Enable privacy for the local device. This makes the device use Resolvable
|
|
|
|
Private Addresses (RPAs) by default.
|
|
|
|
|
|
|
|
Note:
|
|
|
|
Establishing connections as a directed advertiser, or to a directed
|
|
|
|
advertiser is only possible if the controller also supports privacy.
|
2016-04-04 12:55:11 +03:00
|
|
|
|
2022-06-22 10:04:12 +02:00
|
|
|
config BT_PRIVACY_RANDOMIZE_IR
|
|
|
|
bool "Randomize identity root for fallback identities"
|
|
|
|
depends on BT_PRIVACY
|
|
|
|
select BT_SETTINGS
|
|
|
|
help
|
|
|
|
Enabling this option will cause the Host to ignore controller-provided
|
|
|
|
identity roots (IR). The Host will instead use bt_rand to generate
|
|
|
|
identity resolving keys (IRK) and store them in the settings subsystem.
|
|
|
|
|
|
|
|
Setting this config may come with a performance penalty to boot time,
|
|
|
|
as the hardware RNG may need time to generate entropy and will block
|
|
|
|
Bluetooth initialization.
|
|
|
|
|
|
|
|
This option increases privacy, as explained in the following text.
|
|
|
|
|
|
|
|
The IR determines the IRK of the identity. The IRK is used to both
|
|
|
|
generate and resolve (recognize) the private addresses of an identity.
|
|
|
|
The IRK is a shared secret, distributed to peers bonded to that
|
|
|
|
identity.
|
|
|
|
|
|
|
|
An attacker that has stolen or once bonded and retained the IRK can
|
|
|
|
forever resolve addresses from that IRK, even if that bond has been
|
|
|
|
deleted locally.
|
|
|
|
|
|
|
|
Deleting an identity should ideally delete the IRK as well and thereby
|
|
|
|
restore anonymity from previously bonded peers. But unless this config
|
|
|
|
is set, this does not always happen.
|
|
|
|
|
|
|
|
In particular, a factory reset function that wipes the data in the
|
|
|
|
settings subsystem may not affect the controller-provided IRs. If
|
|
|
|
those IRs are reused, this device can be tracked across factory resets.
|
|
|
|
|
|
|
|
For optimal privacy, a new IRK (i.e., identity) should be used per
|
|
|
|
bond. However, this naturally limits advertisements from that identity
|
|
|
|
to be recognizable by only that one bonded device.
|
|
|
|
|
|
|
|
A description of the exact effect of this setting follows.
|
|
|
|
|
|
|
|
If the application has not setup an identity before calling
|
|
|
|
settings_load()/settings_load_subtree("bt") after bt_enable(), the
|
|
|
|
Host will automatically try to load saved identities from the settings
|
|
|
|
subsystem, and if there are none, set up the default identity
|
|
|
|
(BT_ID_DEFAULT).
|
|
|
|
|
|
|
|
If the controller has a public address (HCI_Read_BD_ADDR), that becomes
|
|
|
|
the address of the default identity. The Host will by default try to
|
|
|
|
obtain the IR for that identity from the controller (by Zephyr HCI
|
|
|
|
Read_Key_Hierarchy_Roots). Setting this config randomizes the IR
|
|
|
|
instead.
|
|
|
|
|
|
|
|
If the controller does not have a public address, the Host will try
|
|
|
|
to source the default identity from the static address information
|
|
|
|
from controller (Zephyr HCI Read_Static_Addresses). This results in an
|
|
|
|
identity for each entry in Read_Static_Addresses. Setting this config
|
|
|
|
randomizes the IRs during this process.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_RPA_TIMEOUT
|
2016-07-19 11:55:21 +02:00
|
|
|
int "Resolvable Private Address timeout"
|
2017-08-09 09:21:11 +03:00
|
|
|
depends on BT_PRIVACY
|
2016-07-19 11:55:21 +02:00
|
|
|
default 900
|
|
|
|
range 1 65535
|
|
|
|
help
|
|
|
|
This option defines how often resolvable private address is rotated.
|
|
|
|
Value is provided in seconds and defaults to 900 seconds (15 minutes).
|
|
|
|
|
2022-07-01 13:28:06 +02:00
|
|
|
config BT_RPA_TIMEOUT_DYNAMIC
|
|
|
|
bool "Support setting the Resolvable Private Address timeout at runtime"
|
|
|
|
depends on BT_PRIVACY
|
|
|
|
help
|
|
|
|
This option allows the user to override the default value of
|
|
|
|
the Resolvable Private Address timeout using dedicated APIs.
|
|
|
|
|
2023-11-02 11:52:07 +01:00
|
|
|
config BT_RPA_SHARING
|
|
|
|
bool "Share the Resolvable Private Address between advertising sets"
|
|
|
|
depends on BT_PRIVACY && BT_EXT_ADV
|
|
|
|
help
|
|
|
|
This option configures the advertising sets linked with the same
|
|
|
|
Bluetooth identity to use the same Resolvable Private Address in
|
|
|
|
a given rotation period. After the RPA timeout, the new RPA is
|
|
|
|
generated and shared between the advertising sets in the subsequent
|
|
|
|
rotation period. When this option is disabled, the generated RPAs
|
|
|
|
of the advertising sets differ from each other in a given rotation
|
|
|
|
period.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_SIGNING
|
2015-10-29 13:59:54 +02:00
|
|
|
bool "Data signing support"
|
2015-09-08 14:10:31 +02:00
|
|
|
help
|
|
|
|
This option enables data signing which is used for transferring
|
|
|
|
authenticated data in an unencrypted connection.
|
2015-12-08 16:59:19 +01:00
|
|
|
|
2020-01-23 11:45:20 +01:00
|
|
|
config BT_SMP_APP_PAIRING_ACCEPT
|
|
|
|
bool "Accept or reject pairing initiative"
|
|
|
|
help
|
|
|
|
When receiving pairing request or pairing response query the
|
|
|
|
application whether to accept to proceed with pairing or not. This is
|
|
|
|
for pairing over SMP and does not affect SSP, which will continue
|
|
|
|
pairing without querying the application.
|
|
|
|
The application can return an error code, which is translated into
|
|
|
|
a SMP return value if the pairing is not allowed.
|
|
|
|
|
2018-10-11 13:39:44 +02:00
|
|
|
config BT_SMP_SC_PAIR_ONLY
|
|
|
|
bool "Disable legacy pairing"
|
|
|
|
help
|
|
|
|
This option disables LE legacy pairing and forces LE secure connection
|
|
|
|
pairing. All Security Mode 1 levels can be used with legacy pairing
|
|
|
|
disabled, but pairing with devices that do not support secure
|
|
|
|
connections pairing will not be supported.
|
|
|
|
To force a higher security level use "Secure Connections Only Mode"
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_SMP_SC_ONLY
|
2015-12-08 16:59:19 +01:00
|
|
|
bool "Secure Connections Only Mode"
|
2018-10-11 13:39:44 +02:00
|
|
|
select BT_SMP_SC_PAIR_ONLY
|
2015-12-08 16:59:19 +01:00
|
|
|
help
|
|
|
|
This option enables support for Secure Connection Only Mode. In this
|
|
|
|
mode device shall only use Security Mode 1 Level 4 with exception
|
|
|
|
for services that only require Security Mode 1 Level 1 (no security).
|
|
|
|
Security Mode 1 Level 4 stands for authenticated LE Secure Connections
|
|
|
|
pairing with encryption. Enabling this option disables legacy pairing.
|
2016-02-11 18:27:06 +01:00
|
|
|
|
2020-01-14 16:00:01 +01:00
|
|
|
config BT_SMP_OOB_LEGACY_PAIR_ONLY
|
|
|
|
bool "Force Out Of Band Legacy pairing"
|
|
|
|
depends on !(BT_SMP_SC_PAIR_ONLY || BT_SMP_SC_ONLY)
|
|
|
|
help
|
|
|
|
This option disables Legacy and LE SC pairing and forces legacy OOB.
|
|
|
|
|
|
|
|
config BT_SMP_DISABLE_LEGACY_JW_PASSKEY
|
|
|
|
bool "Forbid usage of insecure legacy pairing methods"
|
|
|
|
depends on !(BT_SMP_SC_PAIR_ONLY || BT_SMP_SC_ONLY || \
|
|
|
|
BT_SMP_OOB_LEGACY_PAIR_ONLY)
|
|
|
|
help
|
|
|
|
This option disables Just Works and Passkey legacy pairing methods to
|
|
|
|
increase security.
|
|
|
|
|
2019-11-07 16:15:50 +01:00
|
|
|
config BT_SMP_ALLOW_UNAUTH_OVERWRITE
|
|
|
|
bool "Allow unauthenticated pairing for paired device"
|
|
|
|
help
|
|
|
|
This option allows all unauthenticated pairing attempts made by the
|
|
|
|
peer where an unauthenticated bond already exists.
|
|
|
|
This would enable cases where an attacker could copy the peer device
|
|
|
|
address to connect and start an unauthenticated pairing procedure
|
|
|
|
to replace the existing bond. When this option is disabled in order
|
|
|
|
to create a new bond the old bond has to be explicitly deleted with
|
|
|
|
bt_unpair.
|
|
|
|
|
2022-08-25 09:26:11 +02:00
|
|
|
config BT_ID_UNPAIR_MATCHING_BONDS
|
|
|
|
bool "Delete bond with same peer with other local identity when bonding"
|
|
|
|
help
|
|
|
|
When a bond is about to complete, find any other bond with the same
|
|
|
|
peer address (or IRK) and `bt_unpair` that bond before the event
|
|
|
|
`pairing_complete`.
|
|
|
|
|
|
|
|
Important: If this option is not enabled, the current implementation
|
|
|
|
will automatically fail the bonding. See "RL limitation" below.
|
|
|
|
|
|
|
|
Important: If this option is not enabled, as Peripheral, it may be too
|
|
|
|
late to abort the bonding. The pairing is failed locally, but it may
|
|
|
|
still be reported as successful on the Central. When this situation
|
|
|
|
occurs, the Zephyr Peripheral will immediately disconnect. See "SMP
|
|
|
|
limitation" below.
|
|
|
|
|
|
|
|
[RL limitation]:
|
|
|
|
The Host implementors have considered it unlikely that applications
|
|
|
|
would ever want to have multiple bonds with the same peer. The
|
|
|
|
implementors prioritize the simplicity of the implementation over this
|
|
|
|
capability.
|
|
|
|
|
|
|
|
The Resolve List on a Controller is not able to accommodate multiple
|
|
|
|
local addresses/IRKs for a single remote address. This would prevent
|
|
|
|
the Host from setting up a one-to-one correspondence between the Host
|
|
|
|
bond database and the Controller Resolve List. The implementation
|
|
|
|
relies on that capability when using the Resolve List. For performance
|
|
|
|
reasons, there is the wish to not fallback to Host Address Resolution
|
|
|
|
in this case.
|
|
|
|
|
|
|
|
[SMP Limitation]:
|
|
|
|
The Paring Failed command of the Security Manager Protocol cannot be
|
|
|
|
sent outside of a Pairing Process. A Pairing Process ends when the
|
|
|
|
last Transport Specific Key to be distributed is acknowledged at
|
|
|
|
link-layer. The Host does not have control over this acknowledgment,
|
|
|
|
and the order of distribution is fixed by the specification.
|
|
|
|
|
2022-11-29 14:57:30 +01:00
|
|
|
config BT_ID_ALLOW_UNAUTH_OVERWRITE
|
|
|
|
bool "Allow unauthenticated pairing with same peer with other local identity"
|
|
|
|
depends on !BT_SMP_ALLOW_UNAUTH_OVERWRITE
|
|
|
|
help
|
|
|
|
This option allows unauthenticated pairing attempts made by the
|
|
|
|
peer where an unauthenticated bond already exists on other local
|
|
|
|
identity. This configuration still blocks unauthenticated pairing
|
|
|
|
attempts on the same local identity. To allow the pairing procedure
|
|
|
|
unconditionally, please see the BT_SMP_ALLOW_UNAUTH_OVERWRITE
|
|
|
|
configuration.
|
|
|
|
|
2020-01-30 08:23:00 +01:00
|
|
|
config BT_SMP_USB_HCI_CTLR_WORKAROUND
|
|
|
|
bool "Workaround for USB HCI controller out-of-order events"
|
|
|
|
depends on BT_TESTING
|
|
|
|
help
|
|
|
|
This option enables support for USB HCI controllers that sometimes
|
|
|
|
send out-of-order HCI events and ACL Data due to using different USB
|
|
|
|
endpoints.
|
2021-09-17 13:49:15 +02:00
|
|
|
Enabling this option will make the central role not require the
|
2020-01-30 08:23:00 +01:00
|
|
|
encryption-change event to be received before accepting key-distribution
|
|
|
|
data.
|
2021-09-17 13:49:15 +02:00
|
|
|
It opens up for a potential vulnerability as the central cannot detect
|
2020-01-30 08:23:00 +01:00
|
|
|
if the keys are distributed over an encrypted link.
|
|
|
|
|
2018-07-30 20:29:40 +03:00
|
|
|
config BT_FIXED_PASSKEY
|
|
|
|
bool "Use a fixed passkey for pairing"
|
|
|
|
help
|
|
|
|
With this option enabled, the application will be able to call the
|
|
|
|
bt_passkey_set() API to set a fixed passkey. If set, the
|
2022-03-16 21:07:43 +00:00
|
|
|
pairing_confirm() callback will be called for all incoming pairings.
|
2018-07-30 20:29:40 +03:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_USE_DEBUG_KEYS
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Security Manager Debug Mode"
|
2016-03-01 10:57:53 +01:00
|
|
|
help
|
|
|
|
This option places Security Manager in a Debug Mode. In this mode
|
|
|
|
predefined Diffie-Hellman private/public key pair is used as described
|
2020-06-15 14:01:46 +02:00
|
|
|
in Core Specification Vol. 3, Part H, 2.3.5.6.1.
|
|
|
|
|
|
|
|
WARNING: This option enables anyone to decrypt on-air traffic.
|
|
|
|
Use of this feature in production is strongly discouraged.
|
2016-03-01 10:57:53 +01:00
|
|
|
|
2018-09-18 12:32:33 +02:00
|
|
|
config BT_BONDABLE
|
|
|
|
bool "Bondable Mode"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This option enables support for Bondable Mode. In this mode,
|
|
|
|
Bonding flag in AuthReq of SMP Pairing Request/Response will be set
|
|
|
|
indicating the support for this mode.
|
|
|
|
|
2019-11-26 13:30:39 +01:00
|
|
|
config BT_BONDING_REQUIRED
|
|
|
|
bool "Always require bonding"
|
|
|
|
depends on BT_BONDABLE
|
|
|
|
help
|
|
|
|
When this option is enabled remote devices are required to always
|
|
|
|
set the bondable flag in their pairing request. Any other kind of
|
|
|
|
requests will be rejected.
|
|
|
|
|
2023-07-03 13:45:30 +02:00
|
|
|
config BT_BONDABLE_PER_CONNECTION
|
|
|
|
bool "Set/clear the bonding flag per-connection [EXPERIMENTAL]"
|
|
|
|
select EXPERIMENTAL
|
|
|
|
help
|
|
|
|
Enable support for the bt_conn_set_bondable API function that is
|
|
|
|
used to set/clear the bonding flag on a per-connection basis.
|
|
|
|
|
2019-08-12 16:02:19 +02:00
|
|
|
config BT_STORE_DEBUG_KEYS
|
|
|
|
bool "Store Debug Mode bonds"
|
|
|
|
help
|
|
|
|
This option enables support for storing bonds where either of devices
|
2020-06-15 14:01:46 +02:00
|
|
|
is using the predefined Diffie-Hellman private/public key pair as
|
|
|
|
described in the Core Specification Vol 3, Part H, 2.3.5.6.1.
|
|
|
|
|
|
|
|
WARNING: This option potentially enables anyone to decrypt on-air
|
|
|
|
traffic.
|
|
|
|
Use of this feature in production is strongly discouraged.
|
2019-08-12 16:02:19 +02:00
|
|
|
|
2019-07-10 14:25:41 +02:00
|
|
|
config BT_SMP_ENFORCE_MITM
|
|
|
|
bool "Enforce MITM protection"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
With this option enabled, the Security Manager will set MITM option in
|
|
|
|
the Authentication Requirements Flags whenever local IO Capabilities
|
|
|
|
allow the generated key to be authenticated.
|
|
|
|
|
2019-03-12 11:04:48 +01:00
|
|
|
config BT_OOB_DATA_FIXED
|
|
|
|
bool "Use a fixed random number for LESC OOB pairing"
|
|
|
|
depends on BT_TESTING
|
|
|
|
help
|
|
|
|
With this option enabled, the application will be able to perform LESC
|
|
|
|
pairing with OOB data that consists of fixed random number and confirm
|
2020-06-15 14:01:46 +02:00
|
|
|
value.
|
|
|
|
|
|
|
|
WARNING: This option stores a hardcoded Out-of-Band value in the image.
|
|
|
|
Use of this feature in production is strongly discouraged.
|
2019-03-12 11:04:48 +01:00
|
|
|
|
2019-09-26 17:27:50 +03:00
|
|
|
config BT_KEYS_OVERWRITE_OLDEST
|
2020-10-16 13:19:02 +11:00
|
|
|
bool "Overwrite the oldest key if key storage is full"
|
2019-09-26 17:27:50 +03:00
|
|
|
help
|
2020-10-16 13:19:02 +11:00
|
|
|
If a pairing attempt occurs and the key storage is full then the
|
|
|
|
oldest key from the set of not currently in use keys will be selected
|
|
|
|
and overwritten by the pairing device.
|
2019-09-26 17:27:50 +03:00
|
|
|
|
|
|
|
config BT_KEYS_SAVE_AGING_COUNTER_ON_PAIRING
|
|
|
|
bool "Store aging counter every time a successful paring occurs"
|
|
|
|
depends on BT_SETTINGS && BT_KEYS_OVERWRITE_OLDEST
|
|
|
|
help
|
|
|
|
With this option enabled, aging counter will be stored in settings every
|
|
|
|
time a successful pairing occurs. This increases flash wear out but offers
|
2019-10-28 16:17:17 -07:00
|
|
|
a more correct finding of the oldest unused pairing info.
|
2019-09-26 17:27:50 +03:00
|
|
|
|
2021-03-31 16:28:33 +02:00
|
|
|
config BT_SMP_MIN_ENC_KEY_SIZE
|
|
|
|
int
|
|
|
|
prompt "Minimum encryption key size accepted in octets" if !BT_SMP_SC_ONLY
|
|
|
|
range 7 16
|
|
|
|
default 16 if BT_SMP_SC_ONLY
|
2022-07-29 10:59:33 +02:00
|
|
|
default 7
|
2021-03-31 16:28:33 +02:00
|
|
|
help
|
|
|
|
This option sets the minimum encryption key size accepted during pairing.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
endif # BT_SMP
|
2015-12-08 16:31:45 +01:00
|
|
|
|
2021-07-20 00:16:38 -07:00
|
|
|
rsource "Kconfig.l2cap"
|
|
|
|
rsource "Kconfig.gatt"
|
2022-02-16 10:32:47 +01:00
|
|
|
rsource "../services/Kconfig"
|
2019-02-05 17:31:05 +02:00
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_MAX_PAIRED
|
2015-10-29 13:59:54 +02:00
|
|
|
int "Maximum number of paired devices"
|
2017-08-09 09:21:11 +03:00
|
|
|
default 0 if !BT_SMP
|
Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
|
|
|
default 1
|
2017-07-04 14:56:40 +03:00
|
|
|
range 0 128
|
2015-05-26 17:20:05 -04:00
|
|
|
help
|
|
|
|
Maximum number of paired Bluetooth devices. The minimum (and
|
|
|
|
default) number is 1.
|
|
|
|
|
2018-09-27 21:03:03 +02:00
|
|
|
config BT_CREATE_CONN_TIMEOUT
|
2019-09-19 01:14:26 -07:00
|
|
|
int "Timeout for pending LE Create Connection command in seconds"
|
|
|
|
default 3
|
2020-03-30 19:23:16 +10:00
|
|
|
range 1 655
|
2019-09-19 01:14:26 -07:00
|
|
|
|
|
|
|
config BT_CONN_PARAM_UPDATE_TIMEOUT
|
|
|
|
int "Peripheral connection parameter update timeout in milliseconds"
|
|
|
|
default 5000
|
2020-10-13 13:04:32 +02:00
|
|
|
range 0 65535
|
2019-09-19 01:14:26 -07:00
|
|
|
help
|
|
|
|
The value is a timeout used by peripheral device to wait until it
|
2020-10-13 12:49:59 +02:00
|
|
|
starts the first connection parameters update procedure after a
|
|
|
|
connection has been established.
|
|
|
|
The connection parameters requested will be the parameters set by the
|
|
|
|
application, or the peripheral preferred connection parameters if
|
|
|
|
configured.
|
|
|
|
The default value is set to 5 seconds, to comply with the Bluetooth
|
|
|
|
Core specification: Core 4.2 Vol 3, Part C, 9.3.12.2:
|
|
|
|
"The Peripheral device should not perform a Connection Parameter
|
|
|
|
Update procedure within 5 seconds after establishing a connection."
|
2019-08-07 04:40:22 +02:00
|
|
|
|
2022-10-13 07:49:44 +05:30
|
|
|
config BT_CONN_PARAM_RETRY_COUNT
|
|
|
|
int "Peripheral connection parameter update retry attempts"
|
|
|
|
default 3
|
|
|
|
range 0 255
|
|
|
|
help
|
|
|
|
This value corresponds to number of times to retry connection
|
|
|
|
parameter update to attain the preferred value set in GATT
|
|
|
|
characteristics in the Peripheral.
|
|
|
|
|
|
|
|
config BT_CONN_PARAM_RETRY_TIMEOUT
|
|
|
|
int "Peripheral connection parameter update retry timeout in milliseconds"
|
|
|
|
default 5000
|
|
|
|
range 0 65535
|
|
|
|
help
|
|
|
|
The value is a timeout used by peripheral device to wait until retry
|
|
|
|
to attempt requesting again the preferred connection parameters.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
endif # BT_CONN
|
2015-11-06 21:49:51 +02:00
|
|
|
|
2018-09-26 19:09:22 +02:00
|
|
|
if BT_OBSERVER
|
|
|
|
config BT_BACKGROUND_SCAN_INTERVAL
|
|
|
|
int "Scan interval used for background scanning in 0.625 ms units"
|
|
|
|
default 2048
|
|
|
|
range 4 16384
|
|
|
|
config BT_BACKGROUND_SCAN_WINDOW
|
|
|
|
int "Scan window used for background scanning in 0.625 ms units"
|
|
|
|
default 18
|
|
|
|
range 4 16384
|
2021-12-20 16:33:49 +01:00
|
|
|
|
|
|
|
config BT_EXT_SCAN_BUF_SIZE
|
|
|
|
int "Maximum advertisement report size"
|
|
|
|
depends on BT_EXT_ADV
|
|
|
|
range 1 1650
|
|
|
|
default 229
|
|
|
|
help
|
|
|
|
Maximum size of an advertisement report in octets. If the advertisement
|
|
|
|
provided by the controller is larger than this buffer size,
|
|
|
|
the remaining data will be discarded.
|
|
|
|
|
2018-09-26 19:09:22 +02:00
|
|
|
endif # BT_OBSERVER
|
|
|
|
|
2017-11-07 12:37:14 +02:00
|
|
|
config BT_SCAN_WITH_IDENTITY
|
|
|
|
bool "Perform active scanning using local identity address"
|
|
|
|
depends on !BT_PRIVACY && (BT_CENTRAL || BT_OBSERVER)
|
|
|
|
help
|
|
|
|
Enable this if you want to perform active scanning using the local
|
2017-11-08 10:35:48 -08:00
|
|
|
identity address as the scanner address. By default the stack will
|
2017-11-07 12:37:14 +02:00
|
|
|
always use a non-resolvable private address (NRPA) in order to avoid
|
2020-01-30 18:44:46 +01:00
|
|
|
disclosing local identity information. By not scanning with the
|
|
|
|
identity address the scanner will receive directed advertise reports
|
|
|
|
for for the local identity. If this use case is required, then enable
|
|
|
|
this option.
|
2017-11-07 12:37:14 +02:00
|
|
|
|
2018-07-31 19:57:08 +02:00
|
|
|
config BT_DEVICE_NAME_DYNAMIC
|
|
|
|
bool "Allow to set Bluetooth device name on runtime"
|
|
|
|
help
|
|
|
|
Enabling this option allows for runtime configuration of Bluetooth
|
|
|
|
device name.
|
|
|
|
|
2018-07-09 15:12:04 +03:00
|
|
|
config BT_DEVICE_NAME_MAX
|
|
|
|
int "Maximum size in bytes for device name"
|
2018-07-31 19:57:08 +02:00
|
|
|
depends on BT_DEVICE_NAME_DYNAMIC
|
2018-07-09 15:12:04 +03:00
|
|
|
default 28
|
2018-07-31 19:57:08 +02:00
|
|
|
range 2 248
|
2018-07-09 15:12:04 +03:00
|
|
|
help
|
|
|
|
Bluetooth device name storage size. Storage can be up to 248 bytes
|
2018-07-31 19:57:08 +02:00
|
|
|
long (excluding NULL termination).
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_DEVICE_NAME
|
2017-01-27 15:20:32 +02:00
|
|
|
string "Bluetooth device name"
|
|
|
|
default "Zephyr"
|
|
|
|
help
|
|
|
|
Bluetooth device name. Name can be up to 248 bytes long (excluding
|
|
|
|
NULL termination). Can be empty string.
|
|
|
|
|
2021-11-24 12:56:13 +01:00
|
|
|
config BT_DEVICE_APPEARANCE_DYNAMIC
|
|
|
|
bool "Runtime Bluetooth Appearance changing"
|
|
|
|
help
|
|
|
|
Enables use of bt_set_appearance.
|
|
|
|
If CONFIG_BT_SETTINGS is set, the appearance is persistently stored.
|
|
|
|
|
2021-11-24 12:56:18 +01:00
|
|
|
config BT_DEVICE_APPEARANCE_GATT_WRITABLE
|
|
|
|
bool "Allow authenticated peers to set GAP Appearance"
|
|
|
|
depends on BT_DEVICE_APPEARANCE_DYNAMIC
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_DEVICE_APPEARANCE
|
2017-06-02 15:36:08 +03:00
|
|
|
int "Bluetooth device appearance"
|
|
|
|
range 0 65535
|
|
|
|
default 0
|
|
|
|
help
|
|
|
|
Bluetooth device appearance. For the list of possible values please
|
|
|
|
consult the following link:
|
|
|
|
https://www.bluetooth.com/specifications/assigned-numbers
|
|
|
|
|
2018-07-04 12:58:10 +03:00
|
|
|
config BT_ID_MAX
|
|
|
|
int "Maximum number of local identities"
|
2022-04-01 18:15:58 +05:30
|
|
|
range 1 250
|
2018-07-04 12:58:10 +03:00
|
|
|
default 1
|
|
|
|
help
|
|
|
|
Maximum number of supported local identity addresses. For most
|
|
|
|
products this is safe to leave as the default value (1).
|
|
|
|
|
2020-10-14 00:50:47 -07:00
|
|
|
config BT_DF
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Direction Finding support [EXPERIMENTAL]"
|
2022-06-15 15:52:04 +02:00
|
|
|
depends on !BT_CTLR || BT_CTLR_DF_SUPPORT
|
2021-10-15 14:14:16 +02:00
|
|
|
select EXPERIMENTAL
|
2020-10-14 00:50:47 -07:00
|
|
|
help
|
|
|
|
Enable support for Bluetooth 5.1 Direction Finding.
|
|
|
|
It will allow to: get information about antennae, configure
|
|
|
|
Constant Tone Extension, transmit CTE and sample incoming CTE.
|
|
|
|
|
2021-12-30 20:30:09 +01:00
|
|
|
if BT_DF
|
|
|
|
|
2021-04-17 19:53:36 +02:00
|
|
|
config BT_DF_CONNECTIONLESS_CTE_RX
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Support for receive of CTE in connectionless mode"
|
2022-06-15 15:52:04 +02:00
|
|
|
depends on !BT_CTLR || BT_CTLR_DF_CTE_RX_SUPPORT
|
2021-04-17 19:53:36 +02:00
|
|
|
help
|
|
|
|
Enable support for reception and sampling of Constant Tone Extension
|
|
|
|
in connectionless mode.
|
|
|
|
|
2022-02-02 22:59:58 +01:00
|
|
|
config BT_DF_CONNECTIONLESS_CTE_TX
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Support for transmission of CTE in connectionless mode"
|
2022-06-15 15:52:04 +02:00
|
|
|
depends on !BT_CTLR || BT_CTLR_DF_CTE_TX_SUPPORT
|
2022-02-02 22:59:58 +01:00
|
|
|
help
|
|
|
|
Enable support for transmission of Constant Tone Extension in
|
|
|
|
connectionless mode.
|
|
|
|
|
2021-05-28 13:41:33 +02:00
|
|
|
config BT_DF_CONNECTION_CTE_RX
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Support for receive of CTE in connection mode"
|
2022-06-15 15:52:04 +02:00
|
|
|
depends on !BT_CTLR || BT_CTLR_DF_CTE_RX_SUPPORT
|
2021-05-28 13:41:33 +02:00
|
|
|
help
|
|
|
|
Enable support for reception and sampling of Constant Tone Extension
|
|
|
|
in connection mode.
|
|
|
|
|
2021-12-30 20:30:09 +01:00
|
|
|
config BT_DF_CONNECTION_CTE_TX
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Support for transmission of CTE in connection mode"
|
2022-06-15 15:52:04 +02:00
|
|
|
depends on !BT_CTLR || BT_CTLR_DF_CTE_TX_SUPPORT
|
2021-12-30 20:30:09 +01:00
|
|
|
help
|
|
|
|
Enable support for transmission of Constant Tone Extension in
|
|
|
|
connection mode.
|
|
|
|
|
2021-12-22 12:50:06 +01:00
|
|
|
config BT_DF_CONNECTION_CTE_REQ
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Support for CTE request procedure in connection mode"
|
2021-12-22 12:50:06 +01:00
|
|
|
depends on BT_DF_CONNECTION_CTE_RX
|
|
|
|
help
|
|
|
|
Enable support for request of Constant Tone Extension in connection
|
|
|
|
mode.
|
|
|
|
|
2021-12-30 20:30:09 +01:00
|
|
|
config BT_DF_CONNECTION_CTE_RSP
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Support for CTE request procedure in connection mode"
|
2021-12-30 20:30:09 +01:00
|
|
|
depends on BT_DF_CONNECTION_CTE_TX
|
|
|
|
help
|
|
|
|
Enable support for request of Constant Tone Extension in connection
|
|
|
|
mode.
|
|
|
|
|
2022-02-02 22:59:58 +01:00
|
|
|
config BT_DF_CTE_RX_AOA
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Antenna switching during CTE reception (AoA) feature"
|
2022-02-02 22:59:58 +01:00
|
|
|
depends on BT_DF_CONNECTIONLESS_CTE_RX || BT_DF_CONNECTION_CTE_RX
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable support for antenna switching during CTE reception.
|
|
|
|
Also known as Angle of Arrival mode.
|
|
|
|
|
|
|
|
config BT_DF_CTE_TX_AOD
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Antenna switching during CTE transmission (AoD) feature"
|
2022-02-02 22:59:58 +01:00
|
|
|
depends on BT_DF_CONNECTIONLESS_CTE_TX || BT_DF_CONNECTION_CTE_TX
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable support for antenna switching during CTE transmission.
|
|
|
|
Also known as Angle of Departure mode.
|
|
|
|
|
2022-07-21 14:56:51 +02:00
|
|
|
config BT_DF_VS_CL_IQ_REPORT_16_BITS_IQ_SAMPLES
|
|
|
|
bool "Use 16 bits signed integer IQ samples in connectionless IQ reports"
|
2024-05-10 15:37:11 +03:00
|
|
|
depends on BT_DF_CONNECTIONLESS_CTE_RX && BT_HCI_VS
|
2022-07-21 14:56:51 +02:00
|
|
|
help
|
|
|
|
Direction Finging connectionless IQ reports provide a set of IQ samples collected during
|
|
|
|
sampling of CTE. Bluetooth 5.3 Core Specification defines IQ samples to be 8 bits signed
|
|
|
|
integer, see Vol 4, Part E section 7.7.65.21. This option enables a vendor specific Host
|
|
|
|
extenstion to handle connectionless IQ reports with samples that are in 16 bit signed
|
|
|
|
integer format.
|
|
|
|
|
|
|
|
config BT_DF_VS_CONN_IQ_REPORT_16_BITS_IQ_SAMPLES
|
|
|
|
bool "Use 16 bits signed integer IQ samples in connection IQ reports"
|
2024-05-10 15:37:11 +03:00
|
|
|
depends on BT_DF_CONNECTION_CTE_RX && BT_HCI_VS
|
2022-07-21 14:56:51 +02:00
|
|
|
help
|
|
|
|
Direction Finging connection IQ reports provide a set of IQ samples collected during
|
|
|
|
sampling of CTE. Bluetooth 5.3 Core Specification defines IQ samples to be 8 bits signed
|
|
|
|
integer, see Vol 4, Part E sections 7.7.65.22. This option enables a vendor specific Host
|
|
|
|
extenstion to handle connection IQ report with samples that are in 16 bit signed integer
|
|
|
|
format.
|
|
|
|
|
2021-12-30 20:30:09 +01:00
|
|
|
endif # BT_DF
|
2017-08-09 09:21:11 +03:00
|
|
|
endif # BT_HCI_HOST
|
2016-11-16 16:24:27 +01:00
|
|
|
|
2018-11-21 13:53:35 +01:00
|
|
|
config BT_ECC
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "ECDH key generation support"
|
2023-03-29 13:11:40 +02:00
|
|
|
default y if BT_SMP && !BT_SMP_OOB_LEGACY_PAIR_ONLY
|
2018-11-21 13:53:35 +01:00
|
|
|
help
|
|
|
|
This option adds support for ECDH HCI commands.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_TINYCRYPT_ECC
|
2020-10-22 10:12:55 +02:00
|
|
|
bool "Emulate ECDH in the Host using TinyCrypt library"
|
2016-11-16 16:24:27 +01:00
|
|
|
select TINYCRYPT
|
2016-07-22 09:54:12 +03:00
|
|
|
select TINYCRYPT_ECC_DH
|
2022-05-30 16:08:11 +02:00
|
|
|
select BT_LONG_WQ
|
2018-11-21 13:53:35 +01:00
|
|
|
depends on BT_ECC && (BT_HCI_RAW || BT_HCI_HOST)
|
2020-10-22 10:12:55 +02:00
|
|
|
default y if BT_CTLR && !BT_CTLR_ECDH
|
2016-07-22 09:54:12 +03:00
|
|
|
help
|
|
|
|
If this option is set TinyCrypt library is used for emulating the
|
|
|
|
ECDH HCI commands and events needed by e.g. LE Secure Connections.
|
2016-11-16 16:24:27 +01:00
|
|
|
In builds including the BLE Host, if not set the controller crypto is
|
|
|
|
used for ECDH and if the controller doesn't support the required HCI
|
|
|
|
commands the LE Secure Connections support will be disabled.
|
|
|
|
In builds including the HCI Raw interface and the BLE Controller, this
|
|
|
|
option injects support for the 2 HCI commands required for LE Secure
|
2018-07-31 10:36:39 +03:00
|
|
|
Connections so that Hosts can make use of those. The option defaults
|
|
|
|
to enabled for a combined build with Zephyr's own controller, since it
|
|
|
|
does not have any special ECC support itself (at least not currently).
|
2015-11-16 15:16:52 +01:00
|
|
|
|
2020-01-29 13:03:23 +01:00
|
|
|
config BT_HOST_CCM
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Host side AES-CCM module"
|
2020-01-29 13:03:23 +01:00
|
|
|
help
|
|
|
|
Enables the software based AES-CCM engine in the host. Will use the
|
|
|
|
controller's AES encryption functions if available, or BT_HOST_CRYPTO
|
|
|
|
otherwise.
|
|
|
|
|
2021-11-23 14:43:44 +01:00
|
|
|
config BT_PER_ADV_SYNC_BUF_SIZE
|
|
|
|
int "Maximum periodic advertising report size"
|
|
|
|
depends on BT_PER_ADV_SYNC
|
|
|
|
range 0 1650
|
|
|
|
default 0
|
|
|
|
help
|
|
|
|
Maximum size of a fragmented periodic advertising report. If the periodic
|
|
|
|
advertising report provided by the controller is fragmented and larger
|
|
|
|
than this buffer size, then the data will be discarded.
|
|
|
|
Unfragmented reports are forwarded as they are received.
|
|
|
|
|
2022-07-07 16:36:53 +02:00
|
|
|
config BT_DEBUG_ISO_DATA
|
|
|
|
bool "ISO channel data debug"
|
2022-11-02 14:31:13 +01:00
|
|
|
depends on BT_ISO_LOG_LEVEL_DBG
|
2022-07-07 16:36:53 +02:00
|
|
|
help
|
|
|
|
Use this option to enable ISO channels data debug logs for the
|
|
|
|
Bluetooth Audio functionality. This will enable debug logs for all
|
|
|
|
ISO data received and sent.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_SMP_SELFTEST
|
2015-10-29 13:59:54 +02:00
|
|
|
bool "Bluetooth SMP self tests executed on init"
|
2022-11-02 14:31:13 +01:00
|
|
|
depends on BT_SMP_LOG_LEVEL_DBG
|
2015-08-12 14:55:09 +03:00
|
|
|
help
|
|
|
|
This option enables SMP self-tests executed on startup
|
|
|
|
to verify security and crypto functions.
|
|
|
|
|
2017-08-09 09:21:11 +03:00
|
|
|
config BT_SMP_FORCE_BREDR
|
2016-09-07 17:30:37 +02:00
|
|
|
bool "Force Bluetooth SMP over BR/EDR"
|
2022-11-02 14:31:13 +01:00
|
|
|
depends on BT_SMP_LOG_LEVEL_DBG
|
2016-09-07 17:30:37 +02:00
|
|
|
help
|
|
|
|
This option enables SMP over BR/EDR even if controller is not
|
2017-04-21 10:55:27 -07:00
|
|
|
supporting BR/EDR Secure Connections. This option is solely for
|
2016-09-07 17:30:37 +02:00
|
|
|
testing and should never be enabled on production devices.
|
|
|
|
|
2020-11-19 09:26:34 +01:00
|
|
|
config BT_LOG_SNIFFER_INFO
|
|
|
|
bool "Bluetooth log information for sniffer"
|
|
|
|
help
|
|
|
|
This option enables the Bluetooth stack to log information such as
|
|
|
|
DH private key and LTK keys, which can be used by sniffers to decrypt
|
|
|
|
the connection without the use of Debug keys.
|
|
|
|
|
|
|
|
WARNING: This option prints out private security keys such as
|
|
|
|
the Long Term Key.
|
|
|
|
Use of this feature in production is strongly discouraged
|
|
|
|
|
2017-12-06 14:59:09 +01:00
|
|
|
config BT_TESTING
|
|
|
|
bool "Bluetooth Testing"
|
|
|
|
help
|
|
|
|
This option enables custom Bluetooth testing interface.
|
|
|
|
Shall only be used for testing purposes.
|
|
|
|
|
2020-07-10 10:46:41 -07:00
|
|
|
config BT_CONN_DISABLE_SECURITY
|
|
|
|
bool "Disable security"
|
|
|
|
depends on BT_TESTING
|
|
|
|
help
|
|
|
|
This option disables security checks for incoming requests enabling
|
|
|
|
to test accessing GATT attributes and L2CAP channels that would
|
|
|
|
otherwise require encryption/authentication in order to be accessed.
|
|
|
|
|
|
|
|
WARNING: This option enables anyone to snoop on-air traffic.
|
|
|
|
Use of this feature in production is strongly discouraged.
|
|
|
|
|
2024-04-25 15:25:27 +08:00
|
|
|
rsource "./classic/Kconfig"
|
2019-05-13 14:57:19 +02:00
|
|
|
|
|
|
|
config BT_HCI_VS_EVT_USER
|
|
|
|
bool "User Vendor-Specific event handling"
|
|
|
|
help
|
|
|
|
Enable registering a callback for delegating to the user the handling of
|
|
|
|
VS events that are not known to the stack
|
2022-02-16 10:30:00 +01:00
|
|
|
|
|
|
|
endmenu
|