nrf9160 download_client does not work anymore in SDK 1.4

[fastfox]

Hi,

My journey for upgrading from SDK 1.3 to 1.4 continues. Now I have hints about how to not make random number generation to crash devzone.nordicsemi.com/.../nrf9160-sdk-1-4-crash-in-random-number-generation and I figured out how to get the URI actually delivered to my device https://github.com/zephyrproject-rtos/zephyr/issues/30135

But now I am stuck with FOTA image download not working anymore. With SDK 1.3 and FW 1.2.1 I have managed to make FOTA upgrade from google cloud my own test server and from AWS S3 bucket which stands behind AWS cloud front. I use HTTPS for downloading.

With SDK 1.4 and FW 1.2.2:

In AWS

- I can see no errors in Cloudfront logs

- In device, download_client receives usually 1-3 partial HTTPS fragments and then " Peer closed connection!". Default amount of retries, ~5% of image downloaded and it fails

In Test server(where I can actually e.g. take pcaps)

- TLS handshake is ok

- I can see that devices sends HTTPS GET to server

- Server responds with HTTP 206 and first partial data

- Device sends (TLS)Encrypted Alert followed by TCP reset

- From device:

00> [00:00:36.674,652] <dbg> download_client.client_connect: fd 2, addrlen 8, fam IPv4, port 443
00> [00:00:46.164,489] <dbg> download_client.download_thread: Receiving up to 2048 bytes at 0x2002163c...
00> [00:00:46.912,780] <wrn> download_client: Peer closed connection

As I use sockets that are offloaded to modem it is really hard to figure out what is wrong. I am also using custom HW and I haven't yet figured out how to get modem traces over SWD.

My setting for download_client are:

CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096
CONFIG_DOWNLOAD_CLIENT_BUF_SIZE=2300
CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_2048=y

And I have tried to fiddle with those -> no effect.

I have tried to read the changes in download_client, but haven't really find any major bugs in that side. One bug probably worth fixing is that It sets timeout for TCP/TLS socket just because COAP is compiled in(should probably set it for UDP sockets only). But fixing that does not make it work. It makes me think though that could it be that ongoing DTLS/COAP/LWM2M connection could be a factor here(in modem side).

Any hints appreciated, thanks

[Martin Lesund]

Hi Fastfox,

As you have seen:

CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_2048 is too big,

while CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_1024 should work just fine.

Optimally you should use the fragment_size here: https://github.com/nrfconnect/sdk-nrf/blob/master/include/net/fota_download.h#L106

And do it dynamically as we do it in e.g. the Azure FOTA Sample: https://github.com/nrfconnect/sdk-nrf/blob/master/subsys/net/lib/azure_fota/azure_fota.c#L529 

---

The issue is that the HTTP header is not a part of the 

CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_2048, so the fragment on 2048 + HTTP header will be too big for the modem to recieve.

best regards,
Martin L.

[fastfox]

Yes, thanks for clarification, it is clear to me now.

I would maybe still propose that you do something to that documentation of the fragment size. Because no matter how may times I read it

When using the BSD library and TLS, the fragment size cannot exceed 2 kB.

Does not sound like you have to use 1024 Fragment size for it to work.

How about that timeout setting to TLS socket? I fixed that to my own fork and I propose that you do the same to upstream. Or correct me if I am mistaken.

[Martin Lesund]

HI Fastfox,
I agree, I will take this internally with the R&D team so we can improve both the documentation and the timeout bug.

Best regards,
Martin L.

[Rafalino]

Hello Martin,

Now that nRF Connect 1.5.0 was released and the modem library freed a lot of memory ,

Can't you handle this limitation of CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_1024 ?