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?

Parents

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

Reply