sbernard31
commented
1 year ago 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 :point_up:, 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 : https://github.com/OpenMobileAlliance/lwm2m-registry/pull/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 : https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/572)
@mlasch, let me know if this helps and which process you plan to use.
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.