Download client (via AWS FOTA) stops at 50% and can't reconnect to AWS

[Marco Russi]

Hello,

I am using the AWS IoT library and I came across an issue when downloading a new image (FOTA) from AWS. The FOTA process starts so the image is downloaded up to 50% where apparently the peer closes the connection (received length is 0) and it the download client can't reconnect to the server. The overall FOTA process then fails. 

My board is the nrf52840DK with the Ethernet W5500 Arduino shield on top. MQTT pub and sub works fine (also with device shadow). I using nRF SDK 2.6.0. 

I attach here my prj.conf file 1072.prj.conf

Here is the error:

More details: as you can see from the prj.conf file, I am using the Zephyr built-in mbedTLS and all communications are with TLS on (MQTTS and HTTPS). 

As you see from the log at around 50% the download client prints "Peer closed connection, will reconnect" and then fails to reconnect throwing a errno 2 (No such file or directory).

Looking at the download client source code, the "Peer closed connection" error is when a received packet has length 0. 

It always fails in the same way. No idea why,

Please help.

Thank you.

Marco 

[Marco Russi]

HI, I have tried that but same result.

Anyway I have just found something interesting: at 50% the AWS server (peer) sends an HTTP header with "connection: close" so the download client reconnects as expected. Indeed the header length is 19 bytes longer than previous headers.

This causes a reconnection attempt that fails due to some reason still to find out but the main problem is that the peer sends "connection: close" in the http header. 

Any idea why that happens?

NOTE: Ingore the BUBU part in the "Peer closed connection, ..." LOG line as I put that do better identify the line in the code. Indeed the piece of code that detects the disconnection request is function http_header_parse in http.c in the nrf download client library :

p = strnstr(client->buf, "\r\nconnection: close", sizeof(client->buf));

if (p) {

LOG_HEXDUMP_DBG(client->buf, *hdr_len, "HTTP response");

LOG_WRN("BUBU Peer closed connection, will re-connect");

client->http.connection_close = true;

}

I have also added the LOG line to print the header when that happens. 

Thanks. 

[Marco Russi]

Hi,

problem solved.

Apparently the http fragmentation size must be 4096. I have added:

CONFIG_DOWNLOAD_CLIENT_BUF_SIZE=4096

CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_4096=y

and it now completes successfully. 

If I define the fragmentation size to 1024 then I fails at 25%. The fact that it was originally failing at 50% is because the size was apparently 2048 by default. 

What do you think ?

Thanks. 

[Håkon Alseth]

Hi,

 

As previously mentioned, the download library is developed and tested with the IP-capable nRF devices in mind, so it highly likely needs to be adjusted/configured differently for your chosen ethernet bridge.

What I can recommend, in addition to what you've already discovered, is to try to disable automatic ranges and see if this happens to have an impact: CONFIG_DOWNLOAD_CLIENT_RANGE_REQUESTS=n

  

Kind regards,

Håkon