Bootstrap needs a client timeout

[sbertin-telular]

If the Client doesn't receive a Finish Bootstrap within EXCHANGE_LIFETIME (247s) of the last command from the server it needs to timeout and consider the bootstrap failed.

[boria8]

Hi, what about using Bootstrap-Server Account Timeout resource as timeout after connection to bootstrap server(and not after receiving acknowledge to bootstrap request)?

[boaks]

Bootstrap-Server Account Timeout resource, LWM2M TS 1.0, E.1, Resource 12

The LwM2M Client MUST purge the LwM2M Bootstrap-Server Account after the timeout value given by this resource. The lowest timeout value is 1. If the value is set to 0, or if this resource is not instantiated, the Bootstrap-Server Account lifetime is infinite.

I don't think, that using a resource out of their (LWm2M T)specification is a good idea. If you want to change the specification, open an issue on the OMA issue page https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues and we will see, if others agree on that idea and may include it into the LWM2M TS 1.1.

I'm not sure, what should cause the loss of the "bootstrap-finish" request. According LWM2M TS 1.0, 8.2.3, table 23, this is a POST in CON, so it's retransmitted, if the client doesn't ACK it. So the probability of that loss should not be high.

[sbertin-telular]

The bootstrap-finish might not be sent if the bootstrap server crashes or is restarted,

[dnav]

Using EXCHANGE_LIFETIME is the way to go as specified in section 5.2.3 of the TS:

Step #2: Bootstrap-Finish Indication When the LwM2M Server has finished to send all the Bootstrap Information to the LwM2M Client, the Server MUST send a Finish Bootstrap Indication to the Client to properly end this phase. In case the LwM2M Client didn’t receive such a Finish Bootstrap Indication in a certain period (EXCHANGE_LIFETIME) after the last received Bootstrap-Server command, the LwM2M Client MUST consider the Bootstrap procedure is failed.

[boaks]

@sbertin-telular

I'm not sure, what you want to achieve with this issue. An explanation of the behaviour? Or an optimization?

If you want an optimization, how should a device distinguish between a bootstrap where the bootstrap server crashes just before the "finish bootstrap" or when bootstrap server crashes still with some more config data to be sent? I think. the device can't ensure, that the bootstrap is finished, except it gets the "finish bootstrap" request.

[sbertin-telular]

I'm looking for correct behavior when the finish bootstrap is not received. Without a timeout, the client will wait forever. With a timeout, the client can attempt the bootstrap again. The timeout is also specified in the LWM2M technical spec.

We have devices that may be in remote locations, without people around. Our customers wouldn't be very happy if they need to send someone out to reboot a device due to a temporary communication problem. It is critical that our devices detect and attempt to recover from what may be a temporary problem.

[dnav]

Your Pull Request is good for me. If the Bootstrap Finish is not received in the $EXCHANGE_LIFETIME seconds after the last command, the Bootstrap is considered as failed. Then the application can decide on what to do (wait some time and retry to Bootstrap in your use case).

Regards,

[boaks]

Sorry, I was thinking in the wrong direction :-). My impression was, that this issue is to go for a "smaller timeout" or "no failure on timeout" because I overseen the prepared PR.

[boria8]

I think that EXCHANGE_LIFETIME timeout solution is a good solution, but it covers only for 1 scenario in which the server is not sending bootstrap end packet ( the client need to update last received packet time). in my opinion, the intention of resource Bootstrap-Server Account Timeout is to handle other scenarios which could lead the client to stuck in bootstrap flow.

[dnav]

Since everyone agreed, I merged the PR #303. I'm also closing this specific issue. Do not hesitate to create a new one if necessary about the Bootstrap-Server Account Timeout.