Download

The Download sample demonstrates how to download a file from an HTTP or a CoAP server, with optional TLS or DTLS. It uses the Downloader library.

Cellular connectivity is supported on the nRF91 Series SiPs, while Wi-Fi® connectivity is supported on the nRF53 or nRF54 Series SoCs hosting the nRF70 Series Wi-Fi companion ICs.

The sample uses the connection manager that provides a common connectivity API for LTE and Wi-Fi stacks.

Requirements

The sample supports the following development kits:

Hardware platforms

PCA

Board name

Board target

Shields

nRF9161 DK

PCA10153

nrf9161dk

nrf9161dk/nrf9161/ns

nRF7120 DK

nrf7120dk

nrf7120dk/nrf7120/cpuapp/ns

nRF7002 DK

PCA10143

nrf7002dk

nrf7002dk/nrf5340/cpuapp/ns

nRF54LM20 DK

PCA10184

nrf54lm20dk

nrf54lm20dk/nrf54lm20b/cpuapp nrf54lm20dk/nrf54lm20a/cpuapp

"nrf7002eb2"

Native Simulator

native_sim

native_sim

For more security, it is recommended to use the */ns variant of the board target. When built for this variant, the sample is configured to compile and run as a non-secure application using security by separation. Therefore, it automatically includes Trusted Firmware-M that prepares the required peripherals and secure services to be available for the application.

Overview

The sample first initializes the device (Modem library and AT communications for cellular devices). Next, if the CONFIG_SAMPLE_PROVISION_CERT is set, it provisions a certificate to the device if the CONFIG_SAMPLE_SECURE_SOCKET option is set. When using an nRF91 Series device, the provisioning of the certificates must be done before connecting to the LTE network since the certificates can only be provisioned when the device is not connected. The certificate file name and security tag can be configured using the CONFIG_SAMPLE_SEC_TAG and the CONFIG_SAMPLE_CERT_FILE options, respectively.

The sample then performs the following actions:

  1. Establishes a connection to the network

  2. Optionally sets up the secure socket options

  3. Uses the Downloader library to download a file.

Selecting the HTTP(S) or CoAP(S) transport

The Downloader library supports both HTTP(S) and CoAP(S), and this sample builds in support for both (CONFIG_DOWNLOADER_TRANSPORT_HTTP and CONFIG_DOWNLOADER_TRANSPORT_COAP, together with CONFIG_COAP). No separate build-time choice is needed to pick between them. The transport is selected automatically at runtime from the scheme of the URL being downloaded (http:// or https:// for HTTP(S), coap:// or coaps:// for CoAP(S)). Set CONFIG_SAMPLE_FILE_URL (with CONFIG_SAMPLE_FILE_CUSTOM selected) to a URL with the appropriate scheme to exercise either transport or security level.

Selecting the HTTP(S) or CoAP(S) transport

The Downloader library supports both HTTP(S) and CoAP(S), and this sample builds in support for both (CONFIG_DOWNLOADER_TRANSPORT_HTTP and CONFIG_DOWNLOADER_TRANSPORT_COAP, together with CONFIG_COAP). No separate build-time choice is needed to pick between them. The transport is selected automatically at runtime from the scheme of the URL being downloaded (http:// or https:// for HTTP(S), coap:// or coaps:// for CoAP(S)). Set CONFIG_SAMPLE_FILE_URL (with CONFIG_SAMPLE_FILE_CUSTOM selected) to a URL with the appropriate scheme to exercise either transport or security level.

Using TLS and DTLS

By default, the CONFIG_SAMPLE_PROVISION_CERT option is set, which means that the sample provisions the certificate found in the samples/net/download/cert folder. The CONFIG_SAMPLE_CERT_FILE option indicates the certificate file name. This certificate will work for the default test files. If you are using a custom download test file, you must provision the correct certificate for the servers from which the certificates will be downloaded.

The certificate is automatically converted to a HEX format in the CMakeLists.txt file. The generated .inc file is then included in the code, where it is provisioned to the modem.

See Certificates for more information.

Mutual TLS (client certificate authentication)

The sample can optionally use mutual TLS (client certificate authentication), for both HTTP(S) and CoAP(S).

Note

This functionality is only supported on Wi-Fi boards and not on cellular boards.

Enable the CONFIG_SAMPLE_PROVISION_CLIENT_CERT option to provision a client certificate and private key, in addition to the CA certificate, under the same security tag. Set CONFIG_SAMPLE_CLIENT_CERT_FILE and CONFIG_SAMPLE_CLIENT_KEY_FILE to the client certificate and private key to provision. This must match what the server you connect to expects.

The sample includes an example client certificate and private key, together with a matching CA trust store, under cert/, for use against the Eclipse Californium CoAP interop server:

  • cert/cf-ca.pem - CA trust store (root + intermediate)

  • cert/cf-client.pem - Client leaf certificate

  • cert/cf-client-key.pem - Client private key (EC P-256)

The wifi-mutual-dtls.conf extra-conf file configures the sample to use these to perform a mutual TLS DTLS download from the Californium interop server.

Wi-Fi

On Wi-Fi boards, networking and TLS/DTLS support are not part of the default configuration and must be added with the wifi.conf extra-conf file, using the download_EXTRA_CONF_FILE sysbuild variable. To perform a mutual DTLS download from the Californium interop server (see Mutual TLS (client certificate authentication)), add the wifi-mutual-dtls.conf extra-conf file on top of wifi.conf.

Configuration

See Configuring and building for information about how to permanently or temporarily change the configuration.

Configuration options

The following sample-specific Kconfig options are used in this sample (located in samples/net/download/Kconfig):

CONFIG_SAMPLE_SECURE_SOCKET

(bool) Use TLS/DTLS

CONFIG_SAMPLE_SEC_TAG

(int) Security tag

CONFIG_SAMPLE_PROVISION_CERT

(bool) Provision root CA certificate

Provision the root CA certificate for the server to the device. This is needed for secure connections. Disable this option to avoid overwriting an existing root CA certificate already stored in the device.

CONFIG_SAMPLE_CERT_FILE

(string) Certificate file name

CONFIG_SAMPLE_PROVISION_CLIENT_CERT

(bool) Provision client certificate and key for mutual TLS

Provision a client certificate and private key in addition to the CA certificate. Required for DTLS/TLS mutual authentication (e.g. with the Californium interop server). Only supported when using the Zephyr TLS credentials store. Not available together with CONFIG_MODEM_KEY_MGMT yet.

CONFIG_SAMPLE_CLIENT_CERT_FILE

(string) Client certificate file

CONFIG_SAMPLE_CLIENT_KEY_FILE

(string) Client private key file

CONFIG_SAMPLE_FILE_HTTP

(bool) HTTP test file

CONFIG_SAMPLE_FILE_HTTPS

(bool) HTTPS test file

CONFIG_SAMPLE_FILE_CUSTOM

(bool) Custom test file

CONFIG_SAMPLE_FILE_URL

(string) URL of resource to download

CONFIG_SAMPLE_COMPUTE_HASH

(bool) Compute sha256 hash

CONFIG_SAMPLE_COMPARE_HASH

(bool) Compare hash

CONFIG_SAMPLE_SHA256_HASH

(string) sha256 hash

Configuring Wi-Fi access point credentials

This sample uses the Wi-Fi credentials library to manage Wi-Fi credentials. Before the sample can connect to a Wi-Fi network, you must configure at least one credential set.

Once you have flashed your device with this sample, connect to your device’s UART interface and add credentials using the following command:

wifi cred add -s NetworkSSID -k SecurityMode -p NetworkPassword

Where NetworkSSID is replaced with the SSID of the Wi-Fi access point you want your device to connect to, and NetworkPassword is its password. SecurityMode is replaced by the number as listed here:

  • 0: None

  • 1: WPA2-PSK

  • 2: WPA2-PSK-256

  • 3: SAE-HNP

  • 4: SAE-H2E

  • 5: SAE-AUTO

  • 6: WAPI

  • 7: EAP-TLS

  • 8: WEP

  • 9: WPA-PSK

  • 10: WPA-Auto-Personal

  • 11: DPP

If you are not sure which security mode to use, enable the CONFIG_NET_L2_WIFI_SHELL Kconfig option and use the wifi scan command to display a list of all accessible networks along with their corresponding security modes. Then either reboot the device or use the wifi cred auto_connect command to manually trigger a connection attempt.

From now on, these credentials will be automatically used when the configured network is reachable.

When building as firmware image for a non-secure board target, the Wi-Fi credentials backend will be set to PSA using TF-M.

See the Wi-Fi: Shell sample document for more details on the wifi cred command.

Wi-Fi static credential options

If you want to configure the credentials statically, set the CONFIG_WIFI_CREDENTIALS_STATIC Kconfig option to y.

Important

Do not use static credentials in production environments.

Other options for statically configuring your Wi-Fi credentials:

Sending traces over UART on an nRF91 Series DK

To send modem traces over UART on an nRF91 Series DK, configuration must be added for the UART device in the devicetree and Kconfig. This is done by adding the modem trace UART snippet when building and programming.

Use the Cellular Monitor app for capturing and analyzing modem traces.

TF-M logging must use the same UART as the application. For more details, see shared TF-M logging.

Building and running

This sample can be found under samples/net/download in the nRF Connect SDK folder structure.

For more security, it is recommended to use the */ns variant of the board target (see the Requirements section above.) When built for this variant, the sample is configured to compile and run as a non-secure application using security by separation. Therefore, it automatically includes Trusted Firmware-M that prepares the required peripherals and secure services to be available for the application.

To build the sample, follow the instructions in Building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.

Note

When building repository applications in the SDK repositories, building with sysbuild is enabled by default. If you work with out-of-tree freestanding applications, you need to manually pass the --sysbuild parameter to every build command or configure west to always use it.

Testing

After programming the sample to your development kit, test it by performing the following steps:

  1. Connect the kit to the computer using a USB cable. The kit is assigned a serial port. Serial ports are referred to as COM ports on Windows, /dev/ttyACM devices on Linux, and /dev/tty devices on macOS. To list Nordic Semiconductor devices connected to your computer together with their serial ports, open a terminal and run the nrfutil device list command. Alternatively, check your operating system’s device manager or its equivalent.

  2. Power on or reset the kit.

  3. Open a serial port connection to the kit using a terminal emulator that supports VT100/ANSI escape characters (for example, the Serial Terminal app). See Testing and optimization for the required settings and steps.

  4. Observe that the sample starts, provisions certificates, and starts to download.

  5. Observe that the progress bar fills up as the download progresses.

  6. Observe that the sample displays the message “Download completed” on the terminal when the download completes.

Sample output

The following output is logged on the terminal when the sample downloads a file from an HTTPS server:

Download client sample started
Provisioning certificate
Connecting to network
IP Up
Network connected
Downloading https://nrfconnectsdk.s3.eu-central-1.amazonaws.com/sample-img-100kb.png
[ 100% ] |==================================================| (102923/102923 bytes)
Download completed in 13679 ms @ 7524 bytes per sec, total 102923 bytes
IP down
Disconnected from network
Socket closed
Bye

Dependencies

This sample uses the following nRF Connect SDK libraries when using an nRF91 Series device:

It uses the following sdk-nrfxlib library:

In addition, it uses the following secure firmware component: