BLE MESH : Replay Cache limitations

RE: BLE MESH : Replay Cache limitations

Amanda Hsieh — Thu, 02 Jun 2022 13:30:26 GMT

Hi,

1. Yes, The max size of backend part for the file cannot be more than `UINT16_MAX`. That means (sizeof(replay_cache_entry_t) + szizeof(uint16_t)) * REPLAY_CACHE_ENTRIES <= UINT16_MAX.

2. Using NON_PERSISTENT for replay cache is not according to the mesh spec.

-Amanda

RE: BLE MESH : Replay Cache limitations

Chris_Dev — Thu, 02 Jun 2022 11:39:10 GMT

I understand that it is limited by RAM, that is why I have mentioned that I have done a memory optimization. What I am trying to show to you are two problems:

"1. When increasing REPLAY_CACHE_ENTRIES to a much larger number, say 4095, I get a mesh assert in mesh_config_backend.c:

line 110: NRF_MESH_ASSERT(size_guard <= UINT16_MAX);

Probably because the mesh config entry for the replay cache is too large?"

"2. I tried working around this by setting:

#define REPLAY_CACHE_STORAGE_STRATEGY MESH_CONFIG_STRATEGY_NON_PERSISTENT

Now I am getting an assert in packet_buffer.c:

line 249: NRF_MESH_ASSERT(m_get_packet(p_buffer, p_buffer->head)->packet_state !=
PACKET_BUFFER_MEM_STATE_RESERVED);"

Somehow the replay cache in RAM and the mesh configuration (FLASH) is not scaling correctly? Maybe somewhere I should increase the number of flash pages the mesh config uses? Also, when I am explicitly stating:

#define REPLAY_CACHE_STORAGE_STRATEGY MESH_CONFIG_STRATEGY_NON_PERSISTENT

I would expect that the replay cache will never be stored in flash (mesh config), so the size of REPLAY_CACHE_ENTRIES should only be dependent on RAM, but now I am getting mesh asserts? Do you see what I am trying to point out?

RE: BLE MESH : Replay Cache limitations

Amanda Hsieh — Thu, 02 Jun 2022 07:24:18 GMT

Hi,

You can increase this number, the trade-off is the bigger size of the m_replay_cache table ( 8 bytes/entry) and the longer time it takes for the node to check the list to avoid a replay attack. The size is limited by the free RAM memory your application has.

-Amanda

RE: BLE MESH : Replay Cache limitations

Chris_Dev — Tue, 31 May 2022 10:07:13 GMT

lHi Amanda,

Perfect, thanks so much.

Then just back to enabling a device to communicate with more unicast addresses:

I have done a memory optimization and I have increased REPLAY_CACHE_ENTRIES to say 1030. That seems to work fine. I am experiencing 2 issues though:

1. When increasing REPLAY_CACHE_ENTRIES to a much larger number, say 4095, I get a mesh assert in mesh_config_backend.c:

line 110: NRF_MESH_ASSERT(size_guard <= UINT16_MAX);

Probably because the config entry for the replay cache is too large?

I tried working around this by setting:

#define REPLAY_CACHE_STORAGE_STRATEGY MESH_CONFIG_STRATEGY_NON_PERSISTENT

Now I am getting an assert in packet_buffer.c:

line 249: NRF_MESH_ASSERT(m_get_packet(p_buffer, p_buffer->head)->packet_state !=
PACKET_BUFFER_MEM_STATE_RESERVED);

What is the right way of expanding the replay cache so that the node can communicate with more devices?

RE: BLE MESH : Replay Cache limitations

Amanda Hsieh — Tue, 31 May 2022 08:03:07 GMT

Hi,

Mesh Profile Specification, section 3.10.7 Node Removal procedure, paragraph 3:
"After a node is removed from a network, its unicast addresses may be reused by a Provisioner. A Provisioner shall only reuse these addresses after the current IV Index (at the time of removal) has been updated (see Section 3.10.5) in order to enable the SEQ numbers to be reused."

The spec requires the provisioner to wait with reusing unicast addresses until there has been a full IV Index Update cycle. In other words, you should not reuse that 0x20 address before the IV Index has been updated.

Regards,
Amanda