I can not get queueing to work

[trickydicky]

Good afternoon,

I am evaluating Anjay. I am testing the queue mode:

• I start the demo with parameter --stored-notification-limit 10
• then I go to offline mode with command "enter-offline"
• I see notifications being queued in the logging: x/10 queued notifications
• then I go to online mode with command "exit-offline"
• I would expect then that registration is updated, but instead, registration is renewed and I lose all queued data

What am I doing wrong?

Thanks in advance

[kFYatek]

Hi,

What server are you connecting to? Also, what security mode are you using?

Notification queuing will only work properly if there is a secure (e.g. DTLS) connection to the server, and the connection can be successfully resumed (as opposed to created anew) when exiting the offline mode. It will never work in NoSec mode.

This behavior is based on the following requirements in the LwM2M Transport TS 1.1.1, section 6.4.3. Registration Interface:

When a new security context is created (e.g. TLS/DTLS), the Client MUST register again to the LwM2M Server.

When the LwM2M Client IP address changes in NoSec mode, the Client MUST register again to the LwM2M Server.

I hope that this information is helpful. If you believe that everything is configured properly but this still doesn't work, then please provide logs that illustrate the issue.

[trickydicky]

I am using leshan master. But I am not using security for the moment, so if that is the reason it is not working, then your info sure is helpful. I will test soon and let you know. Thanks for the quick response

[eabase]

@kFYatek

When a new security context is created (e.g. TLS/DTLS), the Client MUST register again to the LwM2M Server.
When the LwM2M Client IP address changes in NoSec mode, the Client MUST register again to the LwM2M Server.

What does it mean to "register again"?
I'm just running the demo client like this:

./demo.exe --endpoint-name $(hostname) --server-uri coaps://lwm2m.blahblah.com:5684 --security-mode psk --identity aabbcc --key ddeeff

So are you saying I need to repeat that, or something else?

[Kucmasz]

Hi,
You don't need to take any additional action. It means that the Client application will send the Register message again after exiting offline mode instead of Update, even if the registration has not yet expired.
PS: check out --identity-as-string and --key-as-string demo options, they might be more convenient.

[eabase]

@Kucmasz

Thanks that helps!

Another question:
Why does the Endpoint name and Key Identity strings have to be the same?

This is stated here:
https://iotdevzone.avsystem.com/docs/Demo_Projects/Implementing_LwM2M_objects_on_RaspberryPi/#step-4-connecting-to-the-lwm2m-server

[kFYatek]

@eabase
The Key Identity it is used to identify the client on the (D)TLS layer, and so it needs to be unique within a given server site. There is no requirement that it needs to be equal to the Endpoint Name, but it is usually the simplest way to ensure that it is unique and easily recognizable, and so it is typical practice to do so.

However, if you need to set it to something different, you can. When configuring it on Coiote DM, the server will only ensure that it is unique among all devices using the PSK mode enrolled on that particular server.

[trickydicky]

Finally I found some time to check what you suggested, @kFYatek, and yes, when I use DTLS, the queuing works. What I would also like to see is that when the server is temporarily unavailable, that automatically the client goes into buffering mode. I checked this in the current client demo implementation, but when I register, then shut down the server, the client does not queue and worse, it stops observing. I suppose the client can be configured (and is also according to the lwm2m specification) to enter in queueing mode when server unavailable?

I would also expect that the queued values had a timestamp attached