Report client "unbootstrap" or factory reset reason to the server

[mlasch]

Clients which were provisioned by "client initiated bootstrap" might be factory reset manually or out-of-bound. What is the typical approach to report such an event to the server?

From my understanding, in case of a manual factory reset, the client must do a de-registration from the server to close the current session. Also the security and server object would be manipulated or deleted and a new bootstrap sequence should be initiated, maybe only after a reboot.

One approach would be, to signal the bootstrap state before de-registration with a dedicated resource in a core object like "Device Object". The server would need to observe the object or the client can use a LwM2M 1.1 send operation for signaling. The device object already has a resource "Factory Reset" which would do the in-band reset. However there is also no method so signal a successful reset after execution.
As a result, something like a "Factory Reset State" or "Factory Reset Reason" resource might be useful. Using an Enum type would further enable reporting different reset reasons like "manual reset", "reset initiated from server", etc.

[sbernard31]

I understand you want a way for a LWM2M server to know if a LWM2M client did a Reset Factory.

Here I suppose that a Reset Factory will lead to :

• (probably but not mandatory) a client De-register. Note that some client could not implement De-register : "The LwM2M Client SHOULD (not MUST) support the "De-register" operation".
• (probably) a client Reboot.
• (obligatory) a client new Registration.

Using only Core Device Object (Id:3) :

Maybe it's possible for a server to read resource /3/0/3 Firmware version at each new registration and maybe guess if device was reset ?

Using Device Extension Object (Id:3410):

In this object there is some resource which could maybe be used :

ID	Name	Op	Instances	Mandatory	Type	Description
5	Installation date	RW	Single	Optional	Time	Installation date of the device.
10	Additional firmware information	R	Single	Optional	String	Additional information about peripheral firmware versions. The format is left to the vendor.

like for option above ☝️, maybe you can read the resource at each new registration ?

Using Reboot Status Object (Id:10371):

Some time ago, I register an object which contains :

ID	Name	Op	Instances	Mandatory	Type	Description
2	Reset Factory State	R	Single	Optional	Integer	Containing the state of reset factory operation. At start-up the value should be 0 (initial-state). Once the reset factory process is scheduled (exec on /3/O/5), this value must be set to 1 (resetting), it is advised to do that before to send response of Reset Factory resource (/3/0/5) to avoid any race conditions. If reset fails for any reason value must be set to 2 (reset error). If reset succeeds, state should be set to 3 (reset). If the reset factory need a reboot, reboot state(/10371/0/0) resource SHOULD also be updated accordingly. If reset factory need a reboot, in case of successful reset, the value MUST be set to 3 (reset) at device start-up. If it helps implementation, this is tolerated to have this resource set to 3 (reset) at first device start-up.
3	Reset Factory Error Message	R	Single	Optional	String	Containing the error message of the last reset factory failure. This value MUST be set to an empty string on exec on /3/0/5, ideally before to send the response for Reset Factory resource (3/0/5) to avoid any race conditions

Maybe a server could observe Reset Factory State ? Or a client use send Operation about Reset Factory State ? (with value resetting before to start the Reset Factory)

Ideally those resource should haven added to Device Object : OpenMobileAlliance/lwm2m-registry#504

If you want to adapt this object (adding Factory Reset Reason ?), we can adapt it and push a new version in LWM2M Registry but this could take time.

About observing the resource :

My personal understanding is that observation is tied to only 1 registration.
That means if the "reset factory" lead to a new registration, observation done before the reset will not be usable after the new registration. (See related issue at : #572)

@mlasch, let me know if this helps and which process you plan to use.

[mlasch]

I understand you want a way for a LWM2M server to know if a LWM2M client did a Reset Factory.

Yes, for example, when a reset button on the device was pressed.

Maybe it's possible for a server to read resource /3/0/3 Firmware version at each new registration and maybe guess if device was reset ?

It is not guaranteed that the version or any other device property changes. In some cases just the configuration is wiped.

Maybe a server could observe Reset Factory State ? Or a client use send Operation about Reset Factory State ? (with value resetting before to start the Reset Factory)

I think this is the way to go and I agree the Reset Factory State would fit very well into the Device Object to report the result of executing 3/0/5 Factory Reset. Too bad the Reset Factory State resource didn't make it into the Device Object for future LwM2M versions. However we can also survive with an additional object like Reboot Status Object (Id:10371).

My personal understanding is that observation is tied to only 1 registration.
That means if the "reset factory" lead to a new registration, observation done before the reset will not be usable after the new registration.

Not sure I understand you correctly, but in my opinion the client should report the state before doing a deregistration and reboot, kind of sending a "last will". In case of a "factory reset", the client might end up in bootstrap mode without any relation to the old server.

[sbernard31]

Too bad the Reset Factory State resource didn't make it into the Device Object for future LwM2M versions.

👍
I hope that OMA authors will look at this.

Not sure I understand you correctly

I just wanted to clarify that as I understand the specification, an observe relation can not survive to a de-register/register.

in my opinion the client should report the state before doing a deregistration and reboot, kind of sending a "last will".

Yep an probably that "last will", should be in a "confirmable" way so client is sure that server get the information.