6.5. Poor network connectivity

6.5.1. Introduction

It is sometimes the case that the network connectivity is unstable, and during the download some packets get lost. Depending on the underlying download protocol different failures are handled differently.

6.5.2. The definition of “download failure”

Since the variety of protocols may be used to perform the transfer, we need to understand better what conditions cause the download to fail. Let’s consider this case by case:

6.5.2.1. CoAP(s)/UDP

The download fails if either the connection could not be established (e.g. DTLS handshake failure) or when all request retransmissions were performed and no response have been received.

6.5.2.2. CoAP(s)/TCP

The download fails if either the connection could not be established (e.g. TLS handshake failure, remote host is down) or the TCP stack declares the connection as broken, or when there is no response to the request for 5 minutes.

6.5.2.3. HTTP(s)

The download fails due to similar reasons as above. Since HTTP(s) operates over TCP and the TCP stack maintains retransmissions and other things in a way outside of our control. The difference is that here the response timeout is fixed to 30 seconds.

6.5.3. So what happens when the download fails?

When the download fails, the firmware update module calls reset handler. Its implementation is required to cleanup any outstanding resources, and prepare the Client for a potential new download request.

Unfortunately it also means that the firmware image downloaded so far needs to be deleted. In the current implementation there is no support for continuation of firmware download which failed due to network connectivity problems as it doesn’t seem to be supported by the LwM2M protocol.

6.5.4. How can we ensure higher success rate?

As described in previous sections, for any TCP based transport you can’t do much in terms of when the firmware download is considered as failed. The timeouts are, at the time of writing this tutorial, fixed and cannot be changed during runtime.

However, CoAP/UDP provides much more control. CoAP transmission parameters can be provided by the user, who implements get_coap_tx_params, which is a part of anjay_fw_update_handlers_t. If not provided, default CoAP transmission parameters (or passed as part of anjay_configuration_t) will be used.