Store and forward delay overflow if offline

[benninger-mm]

I reported an issue in LBM v4.5.0 that there are frequent store and forward uplinks if offline, see Issue #66. I realized that you fixed this issue in LBM v4.8.0, thanks a lot. Unfortunately, we just found that there is a bug included in the solution that I proposed and that is now part of LBM v4.8.0.

The issue is in the function store_and_forward_flash_compute_next_delay_s which is implemented here. The problem is that sending_try_cpt grows continuously when a device is offline and the computation of delay_s overflows when sending_try_cpt gets bigger than 26.

In other words, uint32_t delay_s = ( 1 << ctx->sending_try_cpt ) * 60 overflows if ctx->sending_try_cpt is bigger than 26. The reason being that 2^26 * 60 ~ 2^32.

The observed behavior in the field was that the devices sent uplinks almost every minute if the device was offline for more than 26h which effectively drained the battery of the devices. I fixed this in the following way:

static uint32_t store_and_forward_flash_compute_next_delay_s( store_and_forward_flash_t* ctx )
{
    if( ctx->sending_try_cpt == 0 )
    {
        return 0;
    }
    // Exponential backoff (2^sending_try_cpt * 60s), avoid overflowing uint32_t (2^26*60 ~ 2^32)
    uint32_t delay_s = 0;
    if ( ctx->sending_try_cpt <= 26 )
    {
        delay_s = ( 1 << ctx->sending_try_cpt ) * 60;
    }
    if( ctx->sending_try_cpt > 26 || delay_s > STORE_AND_FORWARD_DELAY_MAX_S ) 
    {
        delay_s = STORE_AND_FORWARD_DELAY_MAX_S;
    }
    return delay_s + smtc_modem_hal_get_random_nb_in_range( 0, 60 );
}

Sorry for the trouble and I hope this makes it to the next LBM release.

[lbm-team]

Hi,
Thanks for your feedback. This should be fixed in the next coming release.

[lbm-team]

Thank you for your report.

From what I understand, the wrapping issue arises when ctx->sending_try_cpt reaches or exceeds 30. At that point, the upper bits of delay_s are lost due to wrapping, which causes incorrect comparisons against STORE_AND_FORWARD_DELAY_MAX_S = 3600.

For example:

When delay_s = 2^26 × 60 = 0xF000 0000, this equals 4,026,531,840 seconds — which is correctly greater than STORE_AND_FORWARD_DELAY_MAX_S, so the comparison works as expected.

However, when delay_s = 2^30 × 60 = 0x0F 0000 0000, the value wraps around to 0 seconds — which is clearly problematic, as it no longer reflects the intended delay.

but ok, to avoid to loss upper bits we can clamp to 26 tentatives.

static uint32_t store_and_forward_flash_compute_next_delay_s( store_and_forward_flash_t* ctx )
{
    // Computes the exponential delay between each retry attempt to resend a packet that hasn't been acknowledged
    if( ctx->sending_try_cpt == 0 )
    {
        return 0;
    }

    // Avoid overflowing (uint32_t) when compute the delay_s
    uint32_t sending_try_cpt_tmp = ( ctx->sending_try_cpt > 26 ) ? 26 : ctx->sending_try_cpt;

    // Exponential backoff (2^sending_try_cpt * 60s)
    uint32_t delay_s = ( 1 << sending_try_cpt_tmp ) * 60;
    if( delay_s > STORE_AND_FORWARD_DELAY_MAX_S )
    {
        delay_s = STORE_AND_FORWARD_DELAY_MAX_S;
    }
    return delay_s + smtc_modem_hal_get_random_nb_in_range( 0, 60 );
}

[benninger-mm]

Exactly, thanks for taking a look at this. Your proposed solution works as well.