samples: hello: increase TX buffer size for nrf52840dk_nrf52840

[mniestroj]

So far using cert-based authentication was not successful with nrf52840dk_nrf52840 platform. Some of the visible logs are listed below:

[00:00:02.053,253] <inf> golioth_system: Starting connect
...
[00:00:09.409,057] <err> net_pkt: Data buffer (1225) allocation failed.
[00:00:09.409,088] <err> wifi_esp_at: Failed to get net_pkt: len 1225
...
[00:00:13.524,566] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:14.536,102] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:15.556,396] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:16.596,679] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:17.676,971] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:18.544,403] <err> net_pkt: Data buffer (1225) allocation failed.
[00:00:18.544,403] <err> wifi_esp_at: Failed to get net_pkt: len 1225
[00:00:18.777,221] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:19.877,502] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:20.977,783] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:22.078,063] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:22.115,264] <err> wifi_esp_at_offload: Failed to send data: link 1, ret -116
[00:00:23.242,095] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:24.253,662] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:25.273,956] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:26.314,239] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:27.394,531] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:28.261,962] <err> net_pkt: Data buffer (1225) allocation failed.
[00:00:28.261,962] <err> wifi_esp_at: Failed to get net_pkt: len 1225
[00:00:28.494,781] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:29.595,062] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:30.695,343] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:31.795,623] <err> net_pkt: Data buffer (665) allocation failed.
[00:00:32.236,389] <err> wifi_esp_at_offload: Failed to send data: link 1, ret -11
[00:00:32.500,854] <wrn> wifi_esp_at: Busy processing
...
[00:02:37.985,382] <err> net_sock_tls: TLS handshake timeout

The end result is that handshake never succeeds and there is no connection with Golioth server.

Seems that the main reason why handshake never succeeds is lack of network TX buffers. Increasing them from default 16 to 32 solves the problem. There are still allocation failures on the RX path (when receiving data from offloaded WiFi chip and putting them on the networking RX queue), but in the end DTLS handshake still completes.

Increase TX buffer to 32 for nrf52840dk_nrf52840 platform. Do this for both PSK-based and cert-based authentication, as there is no easy mechanism to apply those settings (apart from using default Kconfig values per platform, which is kind of hacky) only for one platform and one configuration variant.

Same issue does not reproduce with esp32 platform, probably due to mix of following reasons:

• 240MHz vs 64MHz clock (ESP32 does the handshake in ~1.5s instead of ~12s in case of nRF52840),
• nRF52 + ESP-AT WiFi is suboptimal in UART (which is used as a communication interface between the two) interrupt handling, where each received byte from network is generating single interrupt, further lowering processing power for general use like processing TLS handshake,
• more time spent on processing handshake results in more retransmissions, which results in more processing power needed for handling interrupts, which once again results in more incoming data, ...,
• TX/RX packets are not completely drained for ESP32 platform due to high network traffic and processing time spent on handshake and interrupt handling.

[github-actions[bot]]

Visit the preview URL for this PR (updated for commit b7ce117):

https://golioth-zephyr-sdk-doxygen-dev--pr333-nrf52840dk-cert-boo0r3ge.web.app

_{(expires Tue, 20 Dec 2022 18:21:15 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: a389eefadf4b4b68a539327b3459dd66c142cf49}

[mniestroj]

There are commit message compliance issues due to long line lengths. All those lines are because of log messages attached. Breaking those would decrease readability, so those checks were ignored on purpose in that case.