Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[fix] samples/net/sockets/http_server fails to build for several nrf5340/cpuapp/ns targets #85201

Merged
merged 3 commits into from
Feb 10, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions samples/net/sockets/http_server/Kconfig
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,7 @@ config NET_SAMPLE_HTTP_SERVER_SERVICE_PORT
config NET_SAMPLE_HTTPS_SERVICE
bool "Enable https service"
depends on NET_SOCKETS_SOCKOPT_TLS || TLS_CREDENTIALS
imply MBEDTLS_PSA_CRYPTO_C if !BUILD_WITH_TFM

if NET_SAMPLE_HTTPS_SERVICE

Expand Down
73 changes: 69 additions & 4 deletions samples/net/sockets/http_server/README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -34,12 +34,21 @@ There are configuration files for various setups in the
* - :zephyr_file:`overlay-netusb.conf <samples/net/sockets/http_server/overlay-netusb.conf>`
- This overlay config can be added for connecting via network USB.

To build and run the application:
* - :zephyr_file:`overlay-tls.conf <samples/net/sockets/http_server/overlay-tls.conf>`
- This overlay config can be added to build the HTTPS variant.

To build and run the HTTP server application:

.. code-block:: bash

$ west build -p auto -b <board_to_use> -t run samples/net/sockets/http_server

For the HTTPS version:

.. code-block:: bash

$ west build -p auto -b <board_to_use> -t run --test samples/net/sockets/http_server/sample.net.sockets.https.server

When the server is up, we can make requests to the server using either HTTP/1.1 or
HTTP/2 protocol from the host machine.

Expand All @@ -56,9 +65,10 @@ HTTP/2 protocol from the host machine.
- Using h2load: ``h2load -n10 http://192.0.2.1/``

Web browsers use stricter security settings for the HTTP/2 protocol. So to use HTTP/2
with a web browser, you must enable ``CONFIG_NET_SAMPLE_HTTPS_SERVICE`` and
``CONFIG_NET_SAMPLE_HTTPS_USE_ALPN``. Additionally the server certificate must be signed
by a CA certificate trusted by your browser.
with a web browser, you must ALPN (add ``-DCONFIG_NET_SAMPLE_HTTPS_USE_ALPN`` to
the west build command) on top of the HTTPS build shown above.
Additionally the server certificate must be signed by a CA certificate trusted
by your browser.

The best way to do this is to generate your own CA certificate:

Expand Down Expand Up @@ -137,6 +147,61 @@ connectivity.
ws.close()


Testing over USB
----------------

Let's see a real example on how the HTTP(S) server can be tested on a real device
using an USB connection toward a Linux host PC. For this purpose let's take an
NRF52840 board as example.

First of all build the sample enabling HTTPS service and flash the board:

.. zephyr-app-commands::
:zephyr-app: samples/net/sockets/http_server/
:board: nrf52840dk/nrf52840
:goals: build
:gen-args: -DCONFIG_NET_SAMPLE_HTTPS_SERVICE=y -DEXTRA_CONF_FILE=overlay-netusb.conf

Then connect the USB cable to the host PC and issue:

.. code-block:: bash

$ ip link show

to get the device name Linux assigned to the USB-Ethernet interface. For the
following let's assume that the name is ``eth-device``.

Now we need to configure IP and routing for this interface:

.. code-block:: bash

$ sudo ip addr add 192.0.2.2/24 dev eth-device
$ sudo ip route add 192.0.2.0/24 dev eth-device

Here:

* we picked an IP address for the interface, i.e. ``192.0.2.2/24``, which is
different form the server one, i.e. :kconfig:option:`CONFIG_NET_CONFIG_MY_IPV4_ADDR`,
but in the allowed IP range defined by the ``/24`` mask.
* we assume that 192.168.0.x range do not conflict with other addresses and
routes in the host system. If that's the case, then all IP addresses should
be fixed (sample, host IP interface, certificate).

Once this is done, it should be possible to test either HTTP and HTTPS with
``curl``:

.. code-block:: bash

$ curl -v --compressed http://192.0.2.1
$ curl -v --compressed https://192.0.2.1

.. note::

To have a successful HTTPS connection ensure to update the CA certificates
of the host Linux system adding
:zephyr_file:`samples/net/sockets/http_server/src/certs/ca_cert.pem` to the
list of known CAs.

Performance Analysis
--------------------

Expand Down
26 changes: 26 additions & 0 deletions samples/net/sockets/http_server/overlay-tls.conf
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
CONFIG_NET_SAMPLE_HTTPS_SERVICE=y

# TLS configuration
CONFIG_MBEDTLS=y
CONFIG_MBEDTLS_BUILTIN=y
CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_MBEDTLS_HEAP_SIZE=60000
CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=2048
CONFIG_NET_SOCKETS_SOCKOPT_TLS=y
CONFIG_NET_SOCKETS_TLS_MAX_CONTEXTS=6
CONFIG_TLS_CREDENTIALS=y
CONFIG_TLS_MAX_CREDENTIALS_NUMBER=5
CONFIG_PSA_WANT_ALG_ECDH=y
CONFIG_PSA_WANT_ALG_ECDSA=y
CONFIG_PSA_WANT_ECC_SECP_R1_256=y
CONFIG_PSA_WANT_KEY_TYPE_ECC_PUBLIC_KEY=y
CONFIG_PSA_WANT_KEY_TYPE_ECC_KEY_PAIR_IMPORT=y
CONFIG_PSA_WANT_KEY_TYPE_ECC_KEY_PAIR_EXPORT=y
CONFIG_PSA_WANT_KEY_TYPE_ECC_KEY_PAIR_GENERATE=y
CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED=y
CONFIG_PSA_WANT_ALG_CCM=y
CONFIG_PSA_WANT_ALG_GCM=y
CONFIG_MBEDTLS_PK_WRITE_C=y
CONFIG_PSA_WANT_ALG_TLS12_PRF=y
CONFIG_PSA_WANT_ALG_SHA_1=y
CONFIG_PSA_WANT_ALG_SHA_256=y
20 changes: 0 additions & 20 deletions samples/net/sockets/http_server/prj.conf
Original file line number Diff line number Diff line change
Expand Up @@ -58,26 +58,6 @@ CONFIG_NET_CONFIG_MY_IPV4_GW="192.0.2.2"
CONFIG_NET_CONFIG_MY_IPV6_ADDR="2001:db8::1"
CONFIG_NET_CONFIG_PEER_IPV6_ADDR="2001:db8::2"

# TLS configuration
CONFIG_MBEDTLS=y
CONFIG_MBEDTLS_BUILTIN=y
CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_MBEDTLS_HEAP_SIZE=60000
CONFIG_MBEDTLS_SSL_MAX_CONTENT_LEN=2048
CONFIG_MBEDTLS_USE_PSA_CRYPTO=n
CONFIG_NET_SOCKETS_SOCKOPT_TLS=y
CONFIG_NET_SOCKETS_TLS_MAX_CONTEXTS=6
CONFIG_TLS_CREDENTIALS=y
CONFIG_TLS_MAX_CREDENTIALS_NUMBER=5
CONFIG_MBEDTLS_ECDH_C=y
CONFIG_MBEDTLS_ECDSA_C=y
CONFIG_MBEDTLS_ECP_C=y
CONFIG_MBEDTLS_ECP_DP_SECP256R1_ENABLED=y
CONFIG_MBEDTLS_KEY_EXCHANGE_RSA_ENABLED=n
Comment on lines -72 to -76
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we leave these and have a separate overlay config file for PSA options so that the legacy compilation works as before?
And then have separate section that tests the non-PSA and PSA compilations in sample.yaml file?
So have something like

sample.net.sockets.http.server: {}
sample.net.sockets.http.server.no_psa:
    filter: not CONFIG_BUILD_WITH_TFM
    extra_configs:
      - CONFIG_MBEDTLS_PSA_CRYPTO_C=y
      here setting the psa overlay
  sample.net.sockets.http.server.psa:
   filter: CONFIG_BUILD_WITH_TFM
      here setting the psa overlay

WDYT?

CONFIG_MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED=y
CONFIG_MBEDTLS_CIPHER_CCM_ENABLED=y
CONFIG_MBEDTLS_CIPHER_GCM_ENABLED=y

# Networking tweaks
# Required to handle large number of consecutive connections,
# e.g. when testing with ApacheBench.
Expand Down
2 changes: 2 additions & 0 deletions samples/net/sockets/http_server/sample.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -16,3 +16,5 @@ common:
- nrf5340dk/nrf5340/cpuapp/ns # Excluding due to ROM overflow.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this removed, the sample will still not fit to that platform?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, correct. I initially thought that moving from legacy Mbed TLS support to TF-M's PSA Crypto on that platform could make the sample build successfully, but I just tried and it's not the case. So I need to revert this leftover. Thanks for noticing.

tests:
sample.net.sockets.http.server: {}
sample.net.sockets.https.server:
extra_args: EXTRA_CONF_FILE="overlay-tls.conf"
Binary file removed samples/net/sockets/http_server/src/certs/ca.der
Binary file not shown.
Loading