fota_download through CoAP doesn't obey the Block2.size value on retry

[Hubert Mis]

Hi Nordic Team,

I would like to report a bug I hit while testing my project.

Project configuration:

• Use fota_download with CoAP protocol to download new images (coap://[host_addr]/[file_path])
• CoAP client and server use Block2 option to host firmware fragments
• The server supports maximum Block2 size 128 bytes

Steps to reproduce:

1. Start downloading firmware image
2. note: the device requests 1024 bytes fragment, when server responds with a 128 bytes fragment, the downloader correctly switches to 128 bytes fragments:
   Request #0
   
   Response #0
   
   Request #1
   
3. Break the connection between the server and the device for a few minutes
4. The device retries downloading the next fragment:
   
   
5. After 4 retries, the device retries Block2 parameters to default (as if fota_download started a brand new downloader session and didn't restore required connection parameters):
   
6. When servers connection is restored, the server can't respond to Block2.num=56 with Block2.size=1024 request, because it's unaligned with the 128 bytes transfer supported by the server

Observed:

While the connection is broken, after 4 retries, fota_download reset CoAP Block2,size and Size2 parameters to default

Expected:

fota_download preserves the CoAP Block2 and Size2 parameters throughout all retries

Bonus request:

I see that the CoAP downloader transport module exposes `downloader_transport_coap_set_config()` function that I could use as a workaround setting `cfg->block_size = COAP_BLOCK_128`. However, I can't find how to use this function with fota_download. A sample presenting this would be helpful!

[Achim Kraus]

> When servers connection is restored, the server can't respond to Block2.num=56 with Block2.size=1024 request, because it's unaligned with the 128 bytes transfer supported by the server

Why do you assume this? Which server implementation you are using?

TLS core mailing list

That starts with block1 but also clarifies block2.

56*1024 == 448*128

So the response should be:

Num: 448, M: 0, SZ: 128

[Hubert Mis]

Sure, my statement was a one-sentence over-simplification. I'm handling the server problem outside of this discussion, because it's not Nordic implementation.

Regardless the server response correctness, I believe the fota client shouldn't change the block size and offsets on retries. It causes unnecessary network traffic and potential flash degradation. I would expect the client to modify the download parameters only on explicit API requests