TLS support using Embassy on Pico2W

help
1

Hi all! Not sure if this belongs in Embedded or Help.

I'm trying to get https request example working using Embassy on a Pico 2W. The example in the Embassy repository is great (updated from the Pico W version, embassy/examples/rp/src/bin/wifi_webrequest.rs at main · embassy-rs/embassy · GitHub). They work for a regular http request, but the TLS version of the example doesn't seem to work. They throw an error at

let mut http_client = HttpClient::new_with_tls(&tcp_client, &dns_client, tls_config);
let url = "https://httpbin.org/json";

let mut request = match http_client.request(Method::GET, url).await

Unfortunately, I don't have a debugging probe, so I can't see the specific error. While I wait for the probe to arrive, any idea what might be causing the problem? TLS handshakes and embedded programming are both at the edge of my knowledge, so I don't know where to begin to look.

I've tried multiple urls, and I've confirmed the urls support the right protocols (GitHub - drogue-iot/reqwless: Rust async HTTP client for embedded/no_std · GitHub).

2

my first guess is the tls version negotiation failed.

not addressing the tls issue, but I want to give some quick tips for debugging:

even without a probe, you can still use serial port or the on-chip usb to print some log lines. I don't have an Pico2W board, but embassy-usb works well on the Pico2, there's usb-to-uart example in rp235x examples directory to demonstrate how to initialize the usb driver.

if you have a spare pico board, you can also flash a probe firmware and use it to debug. I use the firmware for rusty-probe, which is for rp2040 in rust, it should be easy to port to pico2, but I didn't tried it myself. you may also try the debug probe firmware by raspberry pi, which is in C, which supports both pico and pico2.

the rusty probe hardware uses dedicated buffers to isolate and protect the io pins, but the firmware works on a stock pico board too. you can change the pins and setup code accordingly if it makes the wiring easier for you:

3

ok, I see the reqwless has two different tls implementations: mbedtls-rs and embedded-tls, and embedded-tls, which is the default, only supports tls 1.3.

so I tried to use tls 1.3 on the url and got this:

$ curl --verbose --tlsv1.3 https://httpbin.org/json
* Host httpbin.org:443 was resolved.
* IPv6: (none)
* IPv4: 67.202.0.102, 54.205.132.94, 3.222.96.182, 100.55.252.62, 3.93.135.160, 44.217.217.109
*   Trying 67.202.0.102:443...
*   Trying 54.205.132.94:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   OpenSSL default paths (fallback)
* TLSv1.3 (IN), TLS alert, close notify (256):
* TLS connect error: error:00000000:lib(0)::reason(0)
* OpenSSL SSL_connect: SSL_ERROR_ZERO_RETURN in connection to httpbin.org:443 
* closing connection #0
curl: (35) TLS connect error: error:00000000:lib(0)::reason(0)

it seems the server is not capable of tls 1.3, switch to the mbedtls-rs feature and try again.

4

Thanks for the debugging tip and version negotiation tip! I am still looking into both, but I'll report back. As best I can tell, mbedtls-rs is limited to esp32 devices, but I will keep testing.

5

You were correct; the example url (https://httpbin.org/json) doesn't support TLS v1.3. Fortunately, my desired server does support TLS v1.3 ... but it still wasn't working.

It turns out that my issue wasn't the TLS version negotiation, but the algorithm negotiation. The answer was right there in the Readme: by enabling the feature "alloc", it allowed a wider selection of algorithms which allowed me to connect to my desired server. For anyone encountering a similar issue in the future, I found github.com worked great for testing. It currently supports TLS v1.3 and works with or without the "alloc" feature enabled.

Thanks again for your help! I probably would have given up without your help and encouragement that it was solvable.

6

Glad you figured it out! It’s interesting that the issue was algorithm negotiation rather than the TLS version itself. Thanks for sharing the solution and the GitHub testing tip that could definitely help others running into the same problem.