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

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!

  • Hi Matt,

    Not sure by far, in fact, I set up an HTTP server yesterday in order to do the test by myself. I can confirm the problem exists and your solution works on my side now, but I still need to have further discussion with the developers in Japan which has Golden Week vacation time now. They will be back next week. I have raised an internal case to follow up on this issue and will give you an update on your concern. 

    This ticket will keep open until we figure out the cause. Thank you again for your patience.

    Best regards,

    Charlie 

  • Hi Matt,

    I had one deep discussion with our developer. Based on the spec of URI scheme, file <path> should include the leading"/". This is the reason why we keep it and there is no problem when we test with our R&D HTTP test server. 

    After your bug reporting, we did a test on AWS and another HTTP test server, then we see the same problem as you reported. It seems some servers do not like '/' in the beginning. We decided to update the PR with permanent removal of the leading '/', as it is also tested OK with R&D test server. You can find the fixing PR from application: serial_lte_modem: Handle FOTA image under WWW root by junqingzou · Pull Request #7538 · nrfconnect/sdk-nrf (github.com)

    Thanks again for helping us improve our product! We really appreciate your contribution!

    Best regards,

    Charlie

  • Hi Charlie,

    Thanks for the follow up. This all makes sense now. I was server the firmware out of an AWS S3 bucket so it makes sense I was seeing the problem. I'm not a web guy by nature, so I wouldn't have known some servers are picky about the leading slash. Thanks for digging deep on this with me and getting that fix in!

    ~Matt

Related