Client: Reset context without closing and reconfiguring

[pehrnord]

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

[boaks]

Just for information:

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).

[dbarallat]

Based on current test, I agree with @pehrnord: it seems that Leshan is not handling propertly reconfiguration of observations after a client being impacted by a change in its IP address.

Let me add a log, comments:
- client is a wakaama interfacing with Leshan server
- I am adding only an "abstract" of client's log to make it easier to follow
- As a summary:
a) Battery /3/0/9 changes to 56 but fails to send notify because device is offline
b) As a result of above, device forces itself going online to send pending notification
c) Once online: performs first a Register Update, then sends NOTIFY /3/0/9 to server
d) Server responds first with an ACK of Register Update and then...
e) Server responds with a RST to received notification. Under LwM2M, this means server is not recognizing received notification but requests client to stop retransmitting that notificacion
f) After above, client behaves ok as following /3/0/9 resource updates do not trigger any notification

...
targetP: 0x4b8f80a0 uri:/3/0/9
watcherP: 0x4b8f80c0 active: 1 update: 0
...
[engine]: *** event battery changed to 56
...
targetP: 0x4b8f80a0 uri:/3/0/9
watcherP: 0x4b8f80c0 active: 1 update: 1
[engine]: ERROR at sendto(), invalid socket: assuming we are OFFLINE...
[engine]: failed sending 21 bytes to 23.97.187.154:13078 [connP addr: 000001294b8f74f0]
[engine]: *** Observed Failed ==> going offline?
...
[engine]: <<< OFFLINE >>> at 1722706388
[engine]: *** Trigered notification without conditions at /3/0/9
[engine]: > pending notification, requesting going online
...
[engine]: <<< ONLINE >>> at 1722706391
...
[>>]: 126 bytes sent to Server [sock = 320] --> REGISTER UPDATE
...
targetP: 0x4b8f80a0 uri:/3/0/9
watcherP: 0x4b8f80c0 active: 1 update: 1
...
[>>]: 21 bytes sent to Server [sock = 320] --> NOTIFY /3/0/9
NON | 205 CONTENT | | MsgID = 0x5c86 | Token = 0x8D6147F4F372681E | Content type = TLV |
Request Type: DEVICE MNG Uri: /65535/65535/65535
...
[<<]: 8 bytes received from [23.97.187.154] --> ACK REGISTER UPDATE
...
targetP: 0x4b8f80a0 uri:/3/0/9
watcherP: 0x4b8f80c0 active: 1 update: 0
...
[<<]: 4 bytes received from [23.97.187.154] --> acknoledge is a RST NOTIFY
RST | 000 NO_ERROR | | MsgID = 0x5c86 | Token = 0x | Content type = Text plain |
Request Type: DEVICE MNG Uri: /65535/65535/65535 No Payload
...
[engine]: *** event battery changed to 27
...
[engine]: <<< OFFLINE >>> at 1722706488
[engine]: <<< OFFLINE >>> 113 secs to expire
[engine]: *** event battery changed to 72

Summary: Leshan seems not to reconfigure client context after an IP address client's update. Any previous notifications are not longer accepted by server.

[boaks]

FMPOV, an ip-capture will help much more ...
how to ip-capturing

[sbernard31]

@dbarallat did you test with or without DTLS ?

[sbernard31]

Oh it seems there is same question on Leshan Respository : eclipse-leshan/leshan#1636

So I will continue the discussion about Leshan there.