This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF9160 download_client - fault when downloading again

Hi!

I'm using the download_client to fetch one file from time to time. The app is basically a clone of the sample app, just put in a function.

The problem is that if I try to download the same file again, after some time - I get an error and the board resets.

...
[00:06:59.996,948] <inf> download_client: Connecting to xxxx
[00:07:00.302,490] <inf> download_client: Downloading: xxxx[0]
[00:07:00.663,848] <inf> download_client: Downloaded 13/13 bytes (100%)
[00:07:00.676,910] <inf> download_client: Download complete
...
[00:07:28.674,896] <inf> download_client: Connecting to xxxx
[00:07:29.019,439] <inf> download_client: Downloading: xxxx [0]
<err> fatal_error: Resetting system
*** Booting Zephyr OS build v2.4.0-ncs2  ***
[00:00:00.326,995] [1B][0m<inf> mcuboot: Starting bootloader[1B][0m
...

From what I can see, the download client spawns a thread which is never stopped. Maybe I should clean something from the

download_client downloader;  or  download_client_cfg config; data structures?

Please advise how to fix that.

I'm working with NCS 1.4.2 because fo Verizon cert requirements.

Parents
  • Ok problem solved, just leave it there for others:

    To solve this issue, the buffer stored in download_client structure needs to be cleared. But this is a workaround to a bug which is present in http.c of download_client package.

    The problem happends in line 114 of http.c:

    static int http_header_parse(struct download_client *client, size_t *hdr_len)
    {
        char *p;

        p = strstr(client->buf, "\r\n\r\n");
        if (!p) {
            /* Waiting full HTTP header */
            LOG_DBG("Waiting full header in response");
            r

    the strstr function runs over the whole buffer, regardless how much data is there. In case where the downloader runs again, the header parses is able to parse the whole header, from previous run and the hdr_len ends up being too large. The result is pretty obvious:

    [00:00:41.369,750] <inf> download_client: Copying 4294967292 payload bytes

    To fix that I propose this trick to be added to http.c:

    int http_parse(struct download_client *client, size_t len)
    {
        int rc;
        size_t hdr_len;

        /* Accumulate buffer offset */
        client->offset += len;

        client->buf[client->offset] = '\0';

    This will prevent strstr to go too far. Until that the best, but not efficient way is to clear the buf structure every run.

    And remembed to run download_client_disconnect() once done - this client eats sockets otherwise.

  • Note that this fix helps in case where FOTA fails. If you see restart during last packages of FOTA - it's probably caused by this issue.

Reply Children
No Data
Related