Using rd.coap.amsuess.com in plugtests
During plugtests (e. g. for OSCORE or EDHOC), participants often find themselves in separate networks, each with firewalls for incoming traffic. These commands can help them establish connections between each other:
The server operator executes:
$ pip install --user "aiocoap[all]"
The aiocoap installation instructions have details, including that you may want to do this in a virtual environment.
- Start your actual server, on the default or a different port.
$ aiocoap-proxy --reverse --unconditional localhost --register coap+ws://rd.coap.amsuess.com --bind :1234 --register-proxy --register-as yourname.plugtest
If you run your server on a non-default port, adjust
localhostaccordingly. You can also select a non-local host if, for example, your implementation is running on an embedded device in a reachable location.
--bind :1234is there because the proxy is also reachable locally. That port will not be practically used, but currently
aiocoap-proxycan not be started without binding.
The registration is conducted over CoAP-over-WebSockets and not
regularCoAP. This helps around IPv4 address shortage and some shortcomings of the configured proxies as described on the service's main page. Users on IPv6 networks can alternatively choose CoAP-over-TCP (
coap+tcp://…). CoAP-over-UDP usually does not make sense here: If that were publicly reachable, you wouldn't need this setup in the first place.
The server operator tells the client operator the host name (
yourname.plugtest.proxy.rd.coap.amsuess.com), which can also be discovered by running
The client operator then directs their client to that host name.
Things that can go wrong
- The client sends no Uri-Host option.
- This typically manifests in the client seeing the RD itself rather than the advertised service.
As the whole service uses name based virtual hosting, this is non-optional.
Three solutions are available:
- Just send that Uri-Host option. It's really not optional.
- Introduce another reverse proxy on the client side that adds it. Ask me to add instructions here.
- Switch from name based virtual hosting to port based virtual hosting. Possible in theory, but not implemented at this service (or in aiocoap – but both could be changed).
- Registration happened over IPv4 and TCP.
- This results in clients only receiving
errors. Just switch over to CoAP-over-WebSockets or use IPv6 in the registration. An alternative would be for this service to run the IPv4 port multiplexing proxy and the RD in a single host.
4.04 not a server
- Responses are empty.
If a request takes longer to process than a predefined time (aiocoap picks 100ms), a CoAP server (here: the proxy) sends an empty ACK and a separate response rather than a piggy-backed response. CoAP clients need to process either kind of response. As many simple servers always send piggy-backed responses, this setup might be the first situation in which client code encounters a separate response.
If a client library reports 0.00 responses, it implements CoAP incompletely. Tuning the RD proxy's
EMPTY_ACK_DELAYcan provide a temporary hot-fix, but really the client library should be fixed.