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 <Zephyr>/subsys/bluetooth/mesh/Kconfig:697

Included via <Zephyr>/Kconfig:8 → <Zephyr>/Kconfig.zephyr:34 → <Zephyr>/subsys/Kconfig:9 → <Zephyr>/subsys/bluetooth/Kconfig:325

Menu path: (Top) → Sub Systems and OS Services → Bluetooth → Bluetooth Mesh support [EXPERIMENTAL]

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.)