You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running a wakaama client on a connection which might be lost without warning, it is not possible to reset the lwm2m_context in preparation for connection reestablishment. If a connection is reestablished within re-transmission time there will still be items in the transactionList and these will interfere with the (re-)registration process.
Would a "lwm2m_reset" function be a suitable addition for this purpose? Pull request will be added
The text was updated successfully, but these errors were encountered:
Leshan is able to "match" the client using the peer's "Principal".
That means: even if a new handshake is executed, the above layers are not affected by that new handshake, as long as the Principal (identity) stay the same. Some years ago, this was discussed over and over in the oma/lwm2m. On argument against that was RFC 7252 9.1.2. A discussion on the IETF core mailing list then shows, that this definition has some weakness.
So, I'm not that clear, what "will interfere".
Also, as least in the past, some DTLS libraries suppert a "DTLS role exchange" as well. That means, your client may not be even not aware, that there is a new DTLS session (at least not without listen to additional library events).
When running a wakaama client on a connection which might be lost without warning, it is not possible to reset the lwm2m_context in preparation for connection reestablishment. If a connection is reestablished within re-transmission time there will still be items in the transactionList and these will interfere with the (re-)registration process.
Would a "lwm2m_reset" function be a suitable addition for this purpose? Pull request will be added
The text was updated successfully, but these errors were encountered: