:orphan:

.. title:: CONFIG_BT_MESH_RPL_STORE_TIMEOUT

.. kconfig:: CONFIG_BT_MESH_RPL_STORE_TIMEOUT

CONFIG_BT_MESH_RPL_STORE_TIMEOUT
################################

*Minimum interval after which unsaved RPL entries are updated in storage*

Type: ``int``

Help
====

.. code-block:: none

    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
===================

\ :kconfig:`BT_SETTINGS <CONFIG_BT_SETTINGS>` && \ :kconfig:`BT_MESH <CONFIG_BT_MESH>` && \ :kconfig:`BT <CONFIG_BT>`

*(Includes any dependencies from ifs and menus.)*

Default
=======

- 5

Kconfig definition
==================



At ``<Subsystem>/bluetooth/mesh/Kconfig:777``

Included via ``Kconfig:8`` → ``Kconfig.zephyr:44`` → ``<Subsystem>/Kconfig:9`` → ``<Subsystem>/bluetooth/Kconfig:199``

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

.. code-block:: kconfig

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