This is the documentation for the latest (main) development branch of Zephyr. If you are looking for the documentation of previous releases, use the drop-down menu on the left and select the desired version.

CONFIG_BT_MESH_RPL_STORE_TIMEOUT

Minimum interval after which unsaved RPL entries are updated in storage

Type: int

Help

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.

Direct dependencies

BT_SETTINGS && BT_MESH && BT

(Includes any dependencies from ifs and menus.)

Default

  • 5

Kconfig definition

At subsys/bluetooth/mesh/Kconfig:733

Included via Kconfig:8Kconfig.zephyr:42subsys/Kconfig:9subsys/bluetooth/Kconfig:332

Menu path: (Top) → Sub Systems and OS Services → Bluetooth → Bluetooth mesh support

config BT_MESH_RPL_STORE_TIMEOUT
    int "Minimum interval after which unsaved RPL entries are updated in storage"
    range -1 1000000
    default 5
    depends on BT_SETTINGS && BT_MESH && BT
    help
      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.

(The ‘depends on’ condition includes propagated dependencies from ifs and menus.)