Leshan server demo does not seem to manage observations propertly with clients updated after an IP address change

[dbarallat]

Version(s)

server demo hosted at https://leshan.eclipseprojects.io/#/clients

Which components

leshan server demo

Tested With

wakaama client adapted to work in queue mode

What happened

It seems that Leshan is not handling propertly reconfiguration of observations after a client being impacted by a change in its IP address.

How to reproduce

Context explanation:

• Client (supporting queue mode) successfully registers to server
• While registered, server triggers observation of /3/0/9 resource (battery level)
• At some moment, an updated value for /3/0/9 resource does happen (e.g: /3/0/9 = 56)
• Above triggers an attempt from client to send a NOTIFY to server but fails (as client is offline)
• As a result of above point, clients goes to online status (in order to complete pending NOTIFY)
• Once in online status, performs first a REGISTER UPDATE, then sends NOTIFY /3/0/9 to server
• Server responds first with an ACK of Register Update and then...
• 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
• Upon received RST on the /3/0/9 notification, client stops retransmitting battery level on further change

Relevant Output

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

[sbernard31]

@dbarallat did you test with or without DTLS ?

Anyway, you should read LWM2M Observe wiki page and eventually LWM2M Devices with Dynamic IP wiki page

[dbarallat]

I am testing without DTLS.
Client registers with Queue Binding mode ("UQ").

Every time client wakes up and resumed the LwM2M handshake, it starts with a Registration Update (to allow server updating clients' IP/Port).

Am I doing something wrong at client?

Thks

[sbernard31]

I am testing without DTLS.

So this is the expected behavior for coap layer based on Californium.

Am I doing something wrong at client?

I think you should read : https://github.com/eclipse-leshan/leshan/wiki/LWM2M-Observe#for-udp-without-security
After you read it, let me know if this is still unclear to you 🙂

[dbarallat]

Many thanks Simon, very helpful.

As I understand from provided links:

In a non-DTLS scenario, Server will use the pair IP/Port to check received notification against stored UP/Port from observation. Whenever do not match, received notification is cancelled by Server responding a RST back to client. So very little can be done if client IP/Port has changed. As a result, observation state is lost.

In a DTLS scenario, Server will use the DTLS identity to check received notification against stored identification when observation was requested. In case of network disconnection/reconnection, DTLS session resumption is needed if we want to preserve previous observation state.

I am currently focused on building client' app firmware. Once I complete client's logic, I will upgrade connectivity stack with DTLS support knowing that under DTLS scenario the observation state can be persisted if DTLS session resumption is properly managed.

Thanks

Daniel

[sbernard31]

DTLS session resumption is needed if we want to preserve previous observation state.

I'm not sure this is even needed anymore. Maybe just using same identity is needed.
When you will test it , please let me know if resumption is mandatory to persist observation relation. 🙏

[sbernard31]

Could we close this issue ?

[dbarallat]

Yes, sure!!

[dbarallat]

Yes, sure