nRF9161 FOTA + TLS Download Error

Hi,

We are using `fota_download` library on our nRF9161 design running mfw-nrf91x1_2.0.1 to download a firmware upgrade image from our Amazon AWS server location.

When trying to download with TLS enabled, fota_donwload_start function errors out with errno 122: EMSGSIZE, however everything works fine when TLS is not being used. We are also able to download the image if TLS is setup on our local PC/server.

Our current understanding is that the nRF9161 delegates TLS/socket processing to the modem firmware. Adjusting the fragment size in our firmware to a smaller value hasn't resolved the problem, and error 122 persists.
We’ve looked into modifying the TLS settings on AWS server, however that doesn’t seem to be an option as of now.

Wondering if you have any recommendations on how to work around the problem?

0 Øyvind 13 days ago

Hello,

During the summer season, our workforce is currently operating with reduced staff levels throughout the company, which may lead to slight delays in our response time as we await additional resources. Rest assured, we are actively addressing all issues and working diligently to resolve them promptly.

Could you please provide some logs from the issue that you are seeing, both modem traces and application logs?

What version of the nRF Connect SDK are you based on?

Thank you!

Kind regards,
Øyvind
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 OhmMyGod 12 days ago
modem_trace.mtrace

Fullscreen application_logs.txt Download

*** Booting nRF Connect SDK v2.5.0 *** I: Starting bootloader I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok =0x3 I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ ok=0x3 I: Boot source: none I: Image index: 0, Swap type: none I: Bootloader chainload address offset: 0x10000 *** Booting nRF Connect SDK v2.5.0 *** I: LTE Node application v1.0.5 I: Trace thread ready I: Trace level override: 2 I: IMEI: 1400D8DEC570E E: Failed to read data (id: 1, len: 4), err: -2 E: Failed to get Serial ID I: Entered state ST_DISCONNECTED I: Entered state ST_INIT +CEREG: 2,"3BAF","03B05117",7 +CSCON: 1 +CGEV: ME PDN ACT 0,0 +CNEC_ESM: 50,0 +CEREG: 5,"3BAF","03B05117",7,,,"00000000","10101111" I: L4 Event: Connected I: Entered state ST_NETWORK_UP I: Entered state ST_CONNECTED I: Subscribing to: on-config-changed/n/1400D8DEC570E E: Library is in the wrong state (MQTT_STATE_DISCONNECTED), MQTT_STAT E_CONNECTED required E: Failed to subscribe to topics, err: -95 I: Connected successfully I: Upgrading Sensor image I: Upgrading self with image: https://config.api.waites.net/v1/sensor -core/Sensor-IEP-N1_217A7_v1.6.0.bin D: URI checksums 191005400,1987551763,0,0 I: Downloading: v1/sensor-core/Sensor-IEP-N1_217A7_v1.6.0.bin [0] %XTIME: "8A","4270305162428A","01" I: Setting up TLS credentials, sec tag count 1 I: Connecting to config.api.waites.net E: Error in recv(), errno 122 W: Download socket error. 2 retries left... I: Reconnecting... I: Setting up TLS credentials, sec tag count 1 I: Connecting to config.api.waites.net E: Error in recv(), errno 122 W: Download socket error. 1 retries left... I: Reconnecting... I: Setting up TLS credentials, sec tag count 1 I: Connecting to config.api.waites.net E: Error in recv(), errno 122 E: Download client error D: No DFU target was initialized W: Download failed, retries left 4... I: Sleeping... E: Received error from fota downloadHandler, err: 4 +CSCON: 0

Hi,

please see attached the modem trace as well as application log. Please note that the trace was collected from the DevKit to avoid any issues with custom hardware. Here are the details on the SW/HW

Board: nRF9160DK
modem firmware version: mfw_nrf9160_1.3.5
nRF SDK version: v2.5.0
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Øyvind 11 days ago
Hello, and thanks for providing this information.

Most likely you are hitting the TLS limitation when using TLS. How big is the Sensor-IEP-N1_217A7_v1.6.0.bin file?

From the modem FW v1.3.5 release notes

TLS/DTLS

Secure socket buffer size is 2kB.

Maximum length of DTLS datagram is 1kB.

One TLS handshake at a time is supported.

Concurrent secure connections

Maximum server certificate chain size has a limit of 4kB.

Two active connections are supported when serialized DTLS connection exists.

Two active connections are supported when client certificate size is over 1kB.

Two active connections are supported when GNSS acquisition is active.

Three active connections are supported when client certificate size is 1kB or less.

Four serialized DTLS connections are supported.

Server certificate expiry time is not verified.

pkcs#8 is not supported.

Maximum number of supported credentials is 32. The actual amount depends on size of credentials as memory area reserved for credentials may be a limiting factor as well.

Is this you own custom project where you have implemented the fota_download library? Have you tested with the Cellular: HTTP modem delta update to compare?
Kind regards,
Øyvind
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 OhmMyGod 10 days ago

Hi,

We tried a file that is 26kB in length and it failed. We also tried file that is 164 byte long and were able to download it so most likely we are running into the TLS limitation.

What are options to work around the TLS limitation ?

We used fota_download library as is without modifications and integrated it into our project. We will not be able to use the delta update as we have other files that must be downloaded in full.

Thank you
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 Øyvind 8 days ago

Hello,

If you are using HTTPS, then you need to configure as described in Download client for HTTP and HTTPS (TLS 1.2).

Set the CONFIG_DOWNLOAD_CLIENT_BUF_SIZE and CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE Kconfig options, so that the buffer is large enough to accommodate the entire HTTP header of the request and the response.

Have you tried this? E.g. CONFIG_DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_1024=y and CONFIG_DOWNLOAD_CLIENT_BUF_SIZE=2300

From nrf\subsys\net\lib\download_client\Kconfig

config DOWNLOAD_CLIENT_BUF_SIZE
	int "Buffer size (static)"
	range 256 4096
	default 2048
	help
	  Size of the internal buffer used for incoming and
	  outgoing packets. It must be large enough to
	  acommodate for the largest between the HTTP fragment
	  and CoAP block. In case of CoAP, the CoAP header
	  length of 20 bytes should be taken into account.

config DOWNLOAD_CLIENT_HTTP_FRAG_SIZE
	int
	default 256 if DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_256
	default 512 if DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_512
	default 1024 if DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_1024
	default 2048 if DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_2048
	default 4096 if DOWNLOAD_CLIENT_HTTP_FRAG_SIZE_4096

Kind regards,
Øyvind