Using 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:

The server operator tells the client operator the host name (, which can also be discovered by running aiocoap-client coap://

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 4.04 not a server 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.
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_DELAY can provide a temporary hot-fix, but really the client library should be fixed.

Role reversal does not work
If server and client are supposed to switch roles in the application that is being tested, the approach of using a reverse proxy is not applicable – things just won't work because the server only sees the RD as the origin address of any requests. Applications that rely on role reversal should either state that no proxies can be used with them (which in particular rules out this whole setup) or should provide a way for the client to indicate a response address, for which there is no general mechanism in CoAP. For example, the Resource Directory specification itself requires the client to set a base URI if it selects a proxy. (It is not explicit about, but practically requires that, reverse proxies explicitly support the application).