search

eclipse-wakaama / wakaama

Eclipse Wakaama is a C implementation of the Open Mobile Alliance's LightWeight M2M protocol (LWM2M).
BSD 3-Clause "New" or "Revised" License
501 stars 374 forks source link

Client: Reset context without closing and reconfiguring #663

Open pehrnord opened 2 years ago

pehrnord commented 2 years ago

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 commented 2 years ago

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 commented 2 months ago

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:

... 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 commented 2 months ago

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

sbernard31 commented 2 months ago

~@dbarallat did you test with or without DTLS ?~

sbernard31 commented 2 months ago

Oh it seems there is same question on Leshan Respository : https://github.com/eclipse-leshan/leshan/issues/1636

So I will continue the discussion about Leshan there.