nrf Mesh 2.2 about sequence_number problem

[wanglm]

bool replay_cache_has_elem(uint16_t src, uint32_t seqno, uint8_t ivi)
{
    for (uint_fast8_t i = 0; i < REPLAY_CACHE_ENTRIES; ++i)
    {
        if (m_replay_cache[ivi][i].src == src)
        {
            __LOG(LOG_SRC_TRANSPORT, LOG_LEVEL_INFO, "replay cache has elem %u, tag %u\n",
                        m_replay_cache[ivi][i].seqno, seqno);

            if (m_replay_cache[ivi][i].seqno < seqno)
            {
                return false;
            }

            return true;
        }
    }

    /* Not to be added to cache unless successful application decrypt! */
    return false;
}

if m_replay_cache[ivi][i].seqno == 0xFFFFFF, then new message received and seqno == 0 or other value, Whether the message is valid ?

Because the seqno of the new message must be greater than the old seqno in the current code, is there any other code that will reset the m_replay_cache[ivi][i].seqno value ?

[wanglm]

<t:    5162166>, proxy.c,  549, RX GATT PDU type 0x0, len 20
<t:    5162173>, net_packet.c,  230, Unencrypted data: : 0001589DF1EC91220A
<t:    5162176>, replay_cache.c,   94, replay cache has elem 16777215, tag 214
<t:    5186493>, proxy.c,  624, RX
<t:    5186498>, proxy.c,  549, RX GATT PDU type 0x0, len 20
<t:    5186505>, net_packet.c,  230, Unencrypted data: : 000158B9E8815FAB06
<t:    5186508>, replay_cache.c,   94, replay cache has elem 16777215, tag 215

This is the log we printed.Data cannot continue processing

[tesc]

Hi,

You are correct that in the unlikely event that the sequence number reaches 0xFFFFFF the node will no longer be able to send valid messages.

However, the sequence number can and will restart from 0 whenever the IV Index for the network increases, and this should happen long before the sequence number overflows. That means in practice you should never get into such a situation.

Have you actually encountered a sequence number overflow in the field or during testing of realistic usage scenarios?

Regards,
Terje