gcoap_forward_proxy: CoAPS support

[miri64]

Contribution description

Allows to deploy the forward proxy using CoAPS / proxying a CoAPS connection.

Testing procedure

Still needs some work, currently, the proxy reports a Bad Option error, when used with CoAPS...

Issues/PRs references

None

[miri64]

Ok, I found now some hints on why this is not working:

1. The number of DTLS peers is fixed to 1 by the gcoap_dtls example. A proxy of course has at least 2 :(
2. If that is set to 2, I run into the problem, that the proxy runs basically completely in the gcoap thread and tries to use the blocking gcoap_send_req_tl when sending to upstream... It basically stays here in

   RIOT/sys/net/application_layer/gcoap/gcoap.c

   Line 1102 in fb3f1a2

   res = ztimer_msg_receive_timeout(ZTIMER_MSEC, &msg, timeout);

   when trying to establish the handshake, which blocks the gcoap thread. In the meantime the handshake messages from upstream come in, but are not handled in _on_sock_dtls_evt, until the timeout timed out... Maybe an asynchronous version of gcoap_send_req_tl will help here...

[benpicco]

So the idea is that a cllient would connect to the proxy via CoAP and the proxy would forward the connection via CoAPs to the server that it proxies for? That is exactly what we need 😃

[miri64]

So the idea is that a cllient would connect to the proxy via CoAP and the proxy would forward the connection via CoAPs to the server that it proxies for?

The main idea is to have a CoAPS connection at both ends, but yes, in theory it should also work that you have a (unsecure) CoAP connection at one end and a secure CoAPS connection at the other.

[miri64]

Maybe the problem above might not be an issue for this use case, but until it is resolved, this can't be merged of course.

[benpicco]

I'm afraid I figured out why this does not work: In _tl_authenticate() we loop until timeout or a message is received.
This message is supposed to be sent by _on_sock_dtls_evt() which is the event callback for the DTLS socket. That callback is executed by event_loop(&_queue) in the GCoAP thread - the same event loop that handles the proxied request.

That means the event handler will never¹ be executed as _tl_authenticate() is blocking the event handler, we'd either need an async version of the DTLS handshake or move the proxy request to a separate thread.

[1] it will be executed after the timeout, but then it's too late

[miri64]

Yes, that exactly the conclusion I came to in July according to my comment.

[miri64]

With #20454 and #20554 now merged, this should be much easier to get running. Rebased and adopted to current master.

I only compile-tested so far, if you want to merge, please test functionality rigorously.

Nevertheless, I think this can get out of draft state now.

[benpicco]

@mariemC want to give this a try?

[miri64]

Just noticed that I forgot about the new dependency to gcoap_forward_proxy_thread. I added that in the last slew of force pushes.

[riot-ci]

Murdock results

✔️ PASSED

8181e26 fixup! coap/gcoap: unify CoAP ports

Success	Failures	Total	Runtime
10104	0	10105	12m:45s

Artifacts

• Documentation preview

[fabian18]

I think you removed this by accident. Only when no port is specified make and assumption based on the scheme.

[fabian18]

The server endpoint is now stored in client_ep_t::server_ep, so it can be forwarded to the proxy thread.

[fabian18]

We need to add DTLS capability to the gcoap example client, don`t we?

[miri64]

We need to add DTLS capability to the gcoap example client, don`t we?

examples/gcoap_dlts should already suplly that.