Client registration update timeout is broken for lifetime > 93.0s

[mlasch]

For a client lifetime value less than 93s a registration update is sent to the server every lifetime/2 as expected. Above a value of 93.0, a registration update is send every timeout=lifetime-93.0. The number 93.0 is results from a definition COAP_MAX_TRANSMIT_WAIT as a float value.

This can be reproduced by starting the client with lwm2mclient -t 100. After initial registration an update is sent every 7s.

The following section seems to cause the problem:
https://github.com/eclipse/wakaama/blob/a1281ab4abb2199200b406545f7a169b23da143c/core/registration.c#L2071-L2081

[sbernard31]

Not directly linked but in Leshan we are using EXCHANGE_LIFETIME instead of MAX_TRANSMIT_WAIT (rfc7252#section-4.8.2)
I'm not sure what is the best choice. 🤔

We also think that lifetime is not the best way to configure a kind of communication period. For more details, see :

• How to change the periodicity of the updated function in the registration interface to a specific value? eclipse-leshan/leshan#1013 (comment)
• [implementation-specific] issue with smaller lifetime values OpenMobileAlliance/OMA_LwM2M_for_Developers#283 (comment)

Maybe this thoughts could interest you.

[mlasch]

@sbernard31 thanks for providing more context.

The time between registration updates is defined via the lifetime resource in the LWM2M Server IPSO object /1/x/1. There is no RangeEnumeration specified there, so I would guess the whole positive Integer range (up to 64bit signed) in seconds is valid here up to 9,223,372,036,854,775,807.

As far as I understand, there should be no limitations by any CoAP timing parameters since this is a new (confirmed) request issued by the client?

Maybe not directly linked to this issue but, shouldn't we use some time shorter than lifetime/2 between registration updates. That would make the session more robust, because then the second update will arrive at the server with a safety margin and not just when the client expires.
Ok, I think I got what is happening here. Wakaama uses COAP_MAX_TRANSMIT_WAIT as a safety margin which is subtracted from the lifetime as I mentioned above. For values less than COAP_MAX_TRANSMIT_WAIT the registration update timeout it set to lifetime/2. This results in the following behavior:

• lifetime 30s -> update every 15s
• lifetime 90s -> update every 45s
• lifetime 100s -> update every 7s

[sbertin-telular]

I would suggest making the check 2 * COAP_MAX_TRANSMIT_WAIT < nextUpdate. That will make it increase up to 93s which will then be half the lifetime.

Edited: I shouldn't respond before coffee. I had the wrong result after the limit.