Implement Server Object resources

[sbertin-telular]

Resources implemented are: Disable (4), Registration Update Trigger (8),
Bootstrap-Request Trigger (9), and Last Bootstrapped (12).

The default value of 86400 is also assigned to Disable Timeout (5) when
creating instances if not provided.

Signed-off-by: Scott Bertin sbertin@telular.com

[qleisan]

Some hands on observations from running the PR (not necessarily issues). Comments?

• Disable will cause leshan to display "leshan Unable to execute resource /1/0/4 for qleisan : 500 Request cancelled:Request coap://188.149.34.2:50799/1/0/4 canceled".
  Client CLI "list" => status "REGISTRATION HOLD OFF"

• Disable timeout (read) => returns 86400 (todo: investigate function)

• Registration Update Trigger => triggers update...

• Bootstrap-Request Trigger => causes client application to terminate with "State: STATE_BOOTSTRAP_REQUIRED"

• Last Bootstrapped => "1969-12-31T23:59:59Z" (todo: start client with "-b" will another value be set)

[qleisan]

See general observations in conversation

[sbertin-telular]

I'll try to take a look at it in the next couple of days. The Disable and Bootstrap-Request Trigger look to be problems. Not sure about Last Bootstrapped.

Time is tight for me right now. I'm moving 1000 miles a week from now and will be unavailable for 2 weeks after that.

[sbertin-telular]

The disable de-registers before sending the response to the execute. Should be the other way around, but will probably require another server state to change that.

The client exiting on Bootstrap-Request Trigger is likely because it doesn't have a bootstrap server configured. It does not exit if run with -b which sets up a bootstrap server.

Last Bootstrapped is initialized to -1, which matches the time printed.

[sbernard31]

(I looked at this quickly and maybe I didn't get the issue correctly but just in case)

If the issue is about rebooting before the server get the response of the Execute request, a solution could be to use a CON separated response and wait for server acknowledgement of the response before to reboot.

(just an idea)

[sbertin-telular]

Not a reboot, but a disable. The code was sending the deregister before responding at all to the Exec of /1/0/4 to disable. The code processing the execute needs to return before the deregistration is sent. I moved the deregistration to happen on the next lwm2m_step() call. I suppose the response could be lost in transit, but I'm not sure that adding a separate CON response is the right solution.
When the device has been told to stop communicating and stops communicating isn't that a form of confirmation that the Exec was processed even if the response is not received?

[sbernard31]

OK thx for clarification.

When the device has been told to stop communicating and stops communicating isn't that a form of confirmation that the Exec was processed even if the response is not received?

I guess it could be :)

The specification says (talking about disable resource):

If this Resource is executed, this LwM2M Server Object is disabled for a certain period defined in the Disabled Timeout Resource. After receiving “Execute” operation, LwM2M Client MUST send response of the operation and perform de-registration process, and underlying network connection between the Client and Server MUST be disconnected to disable the LwM2M Server account. After the above process, the LwM2M Client MUST NOT send any message to the Server and ignore all the messages from the LwM2M Server for the period.

1. If we want a smooth behavior (without any guess)
   We should be sure that server get the answer to the /1/0/4 EXECUTE request before to deregister. The only way I see is using separated CON response.
   Once we get the ACK of the response, we are sure that server get the response.
   Then we can do a deregister.
   Once we get the answer of the deregister request, then we stop communicating with this server. (if needed we can do some housekeeping about the server connection)

2. Maybe this is not so easy to do (or not desirable for some reason) and so we take the "risk" that /1/0/4 EXECUTE response AND/OR de-register request can be lost.
   In this case this is normal if sometime EXECUTE request failed at server side.

E.g. : Disable will cause leshan to display "leshan Unable to execute resource /1/0/4 for qleisan : 500 Request cancelled:Request coap://188.149.34.2:50799/1/0/4 canceled".

When a client deregister itself, Leshan cleans all about its registration and cancels all ongoing/pending requests linked to it.
This cancellation is forwarded to the application layer (in #561 (comment) case, leshan-server-demo is the application layer)
So I guess we get 500 Request cancelled because we don't get the response in time.
For Leshan demo I'm not sure I will change this behavior, but I guess a production server based on Leshan library (or any other LWM2M server) can decide to not consider a timeout or a cancellation of the EXECUTE request as a failure and could consider a de-registration as a success. (If de-registration is also lost, this begin to be more complicated to guess if this is a success or not 😬 )

[sbertin-telular]

I can take a look at doing a CON response. Since I'm moving this weekend (and most of the following week) it will be a couple weeks before I can though.

[rettichschnidi]

Please rebase on current master once work on this PR resumes.

[qleisan]

@sbertin-telular any chance this gets merged soon? (No urgency other than I have a test that depends on it)

[sbertin-telular]

I haven't had any time to work on it since I moved. I'm not sure yet when I'll be able to get back to it.

[sbertin-telular]

It doesn't look like I'll have time to work on Wakaama anytime soon. If someone else wants to pick this up and finish it, go ahead. That goes for my other changes in https://github.com/sbertin-telular/wakaama/tree/lwm2m_1.1 also. I wish I had time to finish contributing them, but it doesn't seem likely for the rest of the year.

[sbernard31]

Too bad 🙁.
Anyway thx again for all your good job on this project 🙏 !