• State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Subscribers 25 subscribers
  • Views 373 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 287438
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

FOTA in nRF91 SLM gets 404 due to double `/` in file path

user115230

I am unable to do a FOTA with the SLM application on a nRF9160. When I try to do a FOTA with the command below, I get a 404 even though I know the URL exists (real host name redacted). For reference, this is on NCS v1.9.1.

AT#XFOTA=1,"http://our.website.com/app_update.bin"

After digging a bit more, I realized that the http_parser_url lib used from Zephyr is returning the file path including the prefixed /. However, it looks like the Nordic download_client library is also adding an implicit / at the beginning of HTTP GET requests. I confirmed that the HTTP GET request was indeed sending up the path //app_update.bin with some added debug logging statements which explains the 404 I was seeing. See: https://github.com/nrfconnect/sdk-nrf/blob/v1.9.1/subsys/net/lib/download_client/src/http.c#L21. As far as I can tell, my usage of the XFOTA AT command follows the examples in the docs here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/serial_lte_modem/doc/FOTA_AT_commands.html#example

I was able to do a FOTA update by modifying the download_client's GET templates to remove the extra leading /, but this doesn't feel quite right to me, nor a good production solution. I hope I'm missing something simple.

Could I get some input on if I am doing something wrong on my end, and if not if there is a bug here and what a possible fix is?

Thanks!

Parents
  • 0

    A little follow up info, I have a work around solution for now in my code that works for now. This might help shed some light on whats going on.

    // File: slm_at_fota.c
// function: do_fota_start

	if (parser.field_set & (1 << UF_PATH)) {
		/* This is a hack to remove the leading '/' in the file path. The Noridc
		 * download_client library adds another implicit leading `/` which will
		 * result in a 404 due to a double `//` on the path. This looks to be a
		 * bug in Noridc code, but we're not sure at this point.
		 * See: https://devzone.nordicsemi.com/f/nordic-q-a/86861/fota-in-nrf91-slm-gets-404-due-to-double-in-file-path
		 */
		if (parser.field_data[UF_PATH].len >= 1 &&
		    file_uri[parser.field_data[UF_PATH].off] == '/') {
			parser.field_data[UF_PATH].off++;
			parser.field_data[UF_PATH].len--;
		}

		strncpy(path, file_uri + parser.field_data[UF_PATH].off,
			parser.field_data[UF_PATH].len);
	} else {
		LOG_ERR("Parse path error");
		return -EINVAL;
	}

Reply
  • 0

    A little follow up info, I have a work around solution for now in my code that works for now. This might help shed some light on whats going on.

    // File: slm_at_fota.c
// function: do_fota_start

	if (parser.field_set & (1 << UF_PATH)) {
		/* This is a hack to remove the leading '/' in the file path. The Noridc
		 * download_client library adds another implicit leading `/` which will
		 * result in a 404 due to a double `//` on the path. This looks to be a
		 * bug in Noridc code, but we're not sure at this point.
		 * See: https://devzone.nordicsemi.com/f/nordic-q-a/86861/fota-in-nrf91-slm-gets-404-due-to-double-in-file-path
		 */
		if (parser.field_data[UF_PATH].len >= 1 &&
		    file_uri[parser.field_data[UF_PATH].off] == '/') {
			parser.field_data[UF_PATH].off++;
			parser.field_data[UF_PATH].len--;
		}

		strncpy(path, file_uri + parser.field_data[UF_PATH].off,
			parser.field_data[UF_PATH].len);
	} else {
		LOG_ERR("Parse path error");
		return -EINVAL;
	}

Children
No Data
Related
Terms of service