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

Direct dependencies¶

BT_SETTINGS && BT_MESH && BT

(Includes any dependencies from ifs and menus.)

Default¶

5

Kconfig definition¶

At <Zephyr>/subsys/bluetooth/mesh/Kconfig:690

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

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

config BT_MESH_RPL_STORE_TIMEOUT
    int "Minimum frequency that the RPL gets updated in storage"
    range 0 1000000
    default 5
    depends on BT_SETTINGS && BT_MESH && BT
    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).

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