LwM2M FOTA Download Stalls at 1–2% on nRF9160 over NB-IoT/LTE-M

I am using nRF9160 DK with nRF Connect SDK v2.9 and the LwM2M client sample (/samples/cellular/lwm2m_client/), converted from PSK to X.509 certificates.

The device connects successfully to my custom Leshan server on AWS, and works with Onomondo SIM cards. Security handshake with X.509 works fine after adjusting the server settings.

However, firmware update over-the-air (FOTA) fails:

  • The download starts and reports 1–2% progress.

  • After that, the download stalls and no more CoAP requests are observed on the server.

  • This happens even when testing with PSK against the demo LwM2M server.

  • Network connection seems stable, no obvious LTE disconnects, and device registration updates continue.

Also, on the server UI, I see it show me "Request Timeout."

[00:00:15.417,205] <inf> app_lwm2m_client: LwM2M is connected to server
[00:00:15.417,266] <inf> app_lwm2m_client: Obtained date-time from modem
[00:00:38.783,386] <inf> app_lwm2m_client: FOTA download started for instance 0
[00:00:38.784,667] <inf> lwm2m_firmware: Image type 1
[00:00:38.787,139] <inf> lwm2m_firmware: Application firmware download started.
[00:00:57.482,666] <inf> lwm2m_firmware: Downloaded 1%
[00:00:59.722,747] <inf> lwm2m_firmware: Downloaded 2%
[00:01:15.415,527] <dbg> app_lwm2m_client: rd_client_event: Registration update started
[00:01:15.810,852] <inf> net_lwm2m_rd_client: Update callback (code:2.4)
[00:01:15.810,882] <dbg> app_lwm2m_client: rd_client_event: Registration update complete
[00:01:15.810,974] <inf> net_lwm2m_rd_client: Update Done

CONFIG_LWM2M=y
CONFIG_LWM2M_COAP_BLOCK_SIZE=1024
CONFIG_LWM2M_COAP_MAX_MSG_SIZE=2048
CONFIG_LWM2M_CLIENT_UTILS=y
CONFIG_LWM2M_ENGINE_MAX_MESSAGES=15
CONFIG_LWM2M_ENGINE_MAX_PENDING=15
CONFIG_LWM2M_ENGINE_MAX_REPLIES=15

Questions:

  1. Is there a recommended configuration for LwM2M FOTA over NB-IoT/LTE-M for large firmware images?

  2. Should PSM/eDRX be disabled during FOTA, or is there a way to pause registration updates to avoid blocking the download?

  3. What are the recommended CoAP block sizes and engine parameters to reliably transfer large images?

  4. Are there known limitations when using Onomondo SIM + AWS Leshan for large firmware downloads?

Additional Info:

  • MCUboot v2.1.0

  • Zephyr OS v3.7.99

  • LTE-M/NB-IoT tested with Onomondo SIM

Parents
  • Hi,

    You are right that the local IP issue is what caused the HTTP failure, the device on LTE cannot reach 192.168.x.x at all, so that makes sense.

    However, before moving forward, we want to make sure the HTTPS failure is not a separate issue. Even after you provisioned the certificate, the HTTPS download still failed with the same -111 error. This suggests the problem may not just be network accessibility, it is possible that leshan.egconnect.cloud/zephyr.signed.bin is not actually serving the firmware file at all, since Leshan is primarily an LwM2M management server and unless specifically configured to also serve static files, leshan.egconnect.cloud/zephyr.signed.bin may not be returning the file.

    Can you quickly verify this by running:

    curl -v https://leshan.egconnect.cloud/zephyr.signed.bin

    Or simply try opening that URL in a browser. If it returns a 404 or connection error, the file is not being served there and that could be the actual blocker so moving to a public server IP alone will not fix it. Then the firmware binary needs to be hosted on a separate publicly accessible file server such as AWS S3. Let us know what the curl output shows. Thanks.

    Best Regards,
    Syed Maysum

  • Hello, 

    I wasn’t sure how to configure it, so I got stuck

    curl -v https://leshan.egconnect.cloud/zephyr.signed.bin
    COMMENTAIRES : GET with 0-byte payload
    curl : 401 Authorization Required
    nginx
    Au caractère Ligne:1 : 1
    + curl -v https://leshan.egconnect.cloud/zephyr.signed.bin
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidOperation : (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
        + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

    and i think i have a problem with the certificate 

    the error -111 (ECONNREFUSED) you were seeing was caused by a certificate validation failure during the TLS handshake. The nRF9160 modem had the ISRG Root X1 root certificate, but it couldn’t validate your server’s certificate because the E8 intermediate certificate was missing from the chain.

    By provisioning the full chain (E8 + ISRG Root X1) in a single call to modem_key_mgmt_write() using the type MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN, the modem can now properly validate your server’s certificate.

    Best Regards,

    Ben zeineb yassmine 

Reply
  • Hello, 

    I wasn’t sure how to configure it, so I got stuck

    curl -v https://leshan.egconnect.cloud/zephyr.signed.bin
    COMMENTAIRES : GET with 0-byte payload
    curl : 401 Authorization Required
    nginx
    Au caractère Ligne:1 : 1
    + curl -v https://leshan.egconnect.cloud/zephyr.signed.bin
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidOperation : (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
        + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

    and i think i have a problem with the certificate 

    the error -111 (ECONNREFUSED) you were seeing was caused by a certificate validation failure during the TLS handshake. The nRF9160 modem had the ISRG Root X1 root certificate, but it couldn’t validate your server’s certificate because the E8 intermediate certificate was missing from the chain.

    By provisioning the full chain (E8 + ISRG Root X1) in a single call to modem_key_mgmt_write() using the type MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN, the modem can now properly validate your server’s certificate.

    Best Regards,

    Ben zeineb yassmine 

Children
  • Hi,

    Great to hear that, and thanks for sharing so provisioning the full certificate chain in a single modem_key_mgmt_write() call with MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN was the correct fix for your certificate issue.

    Can you confirm whether the FOTA download is now working end to end on the device? If yes, we can close this out.

    Best Regards,
    Syed Maysum

  • it works the solution of tls connexion By provisioning the entire chain( E8 + ISRG Root X1 ) but now i have another problem : 

    • The TLS connection works perfectly.
      The certificate is valid.
      The server refuses access to the file zephyr.signed.bin because authentication is required.

      The server leshan.egconnect.cloud requires authentication to download the firmware file. the server has an authentification to access on 

  • Hi,

    Great that the certificate fix worked

    For the authentication issue, the nRF9160 FOTA downloader makes a plain HTTP GET request and has no built in support for HTTP authentication. The fix needs to be on the server side.

    Is it possible for you to configure nginx to disable authentication just for the firmware file path like auth_basic off for that specific location block. Or alternatively host zephyr.signed.bin on a public AWS S3 bucket and use that URL as the Package URI in Leshan. 

    Best Regards,
    Syed Maysum

Related