net/unicoap: basic CoAP group communication support by elenaf9 · Pull Request #22484 · RIOT-OS/RIOT

elenaf9 · 2026-07-19T11:08:19Z

Contribution description

WIP group communication support for unicoap.
Group communication is based on IP multicast, with non-confirmable messages. Most of it works already out-of-the-box using the gnrc IP multicast support. Two main changes required:

If a request was multicast, we can expect multiple replies. So only clear the memo after a timeout or if the user manually aborted the request.
Add the timeout for multicast requests, until which replies are acceptable.

Testing procedure

Tested successfully with one client and two servers using the unicoap_{client,server} example ¹ with adafruit express boards:

add multicast addrs to servers: ifconfig 8 add ff02::fd
send request from client to multicast addr: unicoap get coap://[ff02::fd]/greeting?name=RIOTer
=> should get two replies in return and eventually an (expected) timeout

Issues/PRs references

Small addition to #22266.

Tracking issue: #21389

Declaration of AI-Tools / LLMs usage:

AI-Tools / LLMs that were used are:

none

+ added shell for the server ↩

riot-ci · 2026-07-19T13:25:17Z

Murdock results

❌ FAILED

48cdf27 fixup! unicoap: basic group communication support

Artifacts

carl-tud

Couple of small things; would it be possible to cancel a multicast request using unicoap_cancel?

mguetschow · 2026-07-20T07:46:38Z

I assume this is an implementation of https://datatracker.ietf.org/doc/html/rfc7390? I was yesterday pointed to https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/ which obsoletes RFC7390 with many more features. Might be worth to have a look. It is about to be published as RFC: https://queue.rfc-editor.org/#draft-ietf-core-groupcomm-bis

elenaf9 · 2026-09-04T14:02:17Z

Basic testing of this PR was successful:

Tested successfully with one client and two servers using the unicoap_{client,server} example ¹ with adafruit express boards:

add multicast addrs to servers: ifconfig 8 add ff02::fd

send request from client to multicast addr: unicoap get coap://[ff02::fd]/greeting?name=RIOTer

=> should get two replies in return and eventually an (expected) timeout

Open TODOs

double check and implement draft-ietf-core-groupcomm-bis-18

Open Questions:

Right now we still return the eventual request timeout as failure to the user. It's not really an error because it's simply the time at which we stop accepting responses. Should we just not inform the user of the timeout in the multicast scenario?

+ added shell for the server ↩

mguetschow

Thanks for coding and testing! Some comments below.

Right now we still return the eventual request timeout as failure to the user. It's not really an error because it's simply the time at which we stop accepting responses. Should we just not inform the user of the timeout in the multicast scenario?

Agree that we should definitely not return it to the user as an error. But we probably want to inform the user about the finished wait time in case it has some resources alloced that it can free afterwards.

Also a prerequisite for the client sync APIs to continue working, I guess. See unicoap_send_request_sync and unicoap_send_request_sync_copy

mguetschow · 2026-09-05T12:43:00Z


-        unicoap_event_schedule(&memo->super.exchange.timeout, _on_response_timeout,
-                               (parameters && parameters->timeout_ms > 0) ? 
-                               parameters->timeout_ms : CONFIG_UNICOAP_TIMEOUT_CLIENT_RESPONSE_MS, 
-                               "client.resp-timeout");
+        if (!multicast) {
+            unicoap_event_schedule(&memo->super.exchange.timeout, _on_response_timeout,
+                                    (parameters && parameters->timeout_ms > 0) ?
+                                   parameters->timeout_ms :
+                                   CONFIG_UNICOAP_TIMEOUT_CLIENT_RESPONSE_MS,
+                                    "client.resp-timeout");
+        }
+        else if (CONFIG_UNICOAP_TIMEOUT_CLIENT_MULTICAST_RESPONSE_MS > 0) {
+            unicoap_event_schedule(&memo->super.exchange.timeout, _on_response_timeout,
+                                    (parameters && parameters->timeout_ms > 0) ?
+                                   parameters->timeout_ms :
+                                   CONFIG_UNICOAP_TIMEOUT_CLIENT_MULTICAST_RESPONSE_MS,
+                                    "client.resp-timeout");
+        }
    }
+


Suggested change

unicoap_event_schedule(&memo->super.exchange.timeout, _on_response_timeout,

(parameters && parameters->timeout_ms > 0) ?

parameters->timeout_ms : CONFIG_UNICOAP_TIMEOUT_CLIENT_RESPONSE_MS,

"client.resp-timeout");

if (!multicast) {

unicoap_event_schedule(&memo->super.exchange.timeout, _on_response_timeout,

(parameters && parameters->timeout_ms > 0) ?

parameters->timeout_ms :

CONFIG_UNICOAP_TIMEOUT_CLIENT_RESPONSE_MS,

"client.resp-timeout");

}

else if (CONFIG_UNICOAP_TIMEOUT_CLIENT_MULTICAST_RESPONSE_MS > 0) {

unicoap_event_schedule(&memo->super.exchange.timeout, _on_response_timeout,

(parameters && parameters->timeout_ms > 0) ?

parameters->timeout_ms :

CONFIG_UNICOAP_TIMEOUT_CLIENT_MULTICAST_RESPONSE_MS,

"client.resp-timeout");

}

}

uint32_t timeout_ms =

(parameters && parameters->timeout_ms > 0) ? parameters->timeout_ms :

(multicast) ? CONFIG_UNICOAP_TIMEOUT_CLIENT_MULTICAST_RESPONSE_MS :

CONFIG_UNICOAP_TIMEOUT_CLIENT_RESPONSE_MS;

if (timeout_ms > 0) {

unicoap_event_schedule(&memo->super.exchange.timeout, _on_response_timeout,

timeout_ms, "client.resp-timeout");

}

}

is timeout_ms == 0 even a sensible value?

timeout == 0 is used to disable the timeout, see #22484 (comment).

Oh I see. That's missing in the documentation of the config value right now. Also what does it mean to be disabled? Wouldn't the client then be unable to free up any resources it may have used for the transmission forever? Or does it not need transmissions for multicast anyways?

I could think of DTLS sessions e.g.. But anyways, how about interplay with DTLS for multicast? Probably just not supported? Is is caught somewhere right now?

That's missing in the documentation of the config value right now

https://github.com/elenaf9/RIOT/blob/48cdf27bbacef19b4cd22323af5f04e29a9b9954/sys/include/net/unicoap/config.h#L286

Wouldn't the client then be unable to free up any resources it may have used for the transmission forever?

The user can still free up the resource by manually calling unicoap_cancel_request. This was discussed with @carl-tud out-of-band before.

But anyways, how about interplay with DTLS for multicast? Probably just not supported? Is is caught somewhere right now?

Per RFC 7390, the DTLS- based approach for CoAP is only for unicast and does not support group security features. Draft draft-ietf-core-groupcomm-bis specifies Group OSCORE as the default.
For this PR I think it's out of scope, but I'll add a check to catch the DTLS case.

mguetschow · 2026-09-05T12:46:30Z

+
+        if (endpoint && !unicoap_endpoint_is_equal(&memo->super.endpoint,
+                                                   endpoint) && !_is_multicast(memo)) {
+            continue;
+        }
+
+        if (token_length == sizeof(memo->token) && memcmp(memo->token, token, token_length) == 0) {
            return memo;
        }


Not sure I understand that reasoning on the first glance. Could you elaborate?

I would expect: if multicast, just match on token. otherwise check endpoint and token. or does endpoint_is_equal does some special handling of multicast adresses?

I would expect: if multicast, just match on token. otherwise check endpoint. or does endpoint_is_equal does some special handling of multicast adresses?

Yes, that's what this implements: if the endpoint doesn't match and it's not multicast =>continue. But will move the is_multicast check to the beginning so that we check that before comparing the endpoint.

then i would propose:

if ((multicast || (endpoint && is_equal)) && token-comparison)

in a single if-clause to avoid the continue?

That's how it was before. I personally find these very long multi-line if-clauses harder to read and understand. But I don't feel strongly about it. Will change it back.

mguetschow · 2026-09-05T12:49:08Z

+            if (!_is_multicast(memo)) {
+                unicoap_event_cancel(&memo->super.exchange.timeout);


maybe add a comment why we don't cancel for multicast.

Apply suggestions from code review Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>

github-actions Bot added Area: network Area: Networking Area: CoAP Area: Constrained Application Protocol implementations Area: sys Area: System labels Jul 19, 2026

elenaf9 commented Jul 19, 2026

View reviewed changes

Comment thread sys/net/application_layer/unicoap/state.c Outdated

Comment thread sys/include/net/unicoap/client.h Outdated

elenaf9 changed the title ~~unicoap: basic group communication support~~ unicoap: basic CoAP group communication support Jul 19, 2026

AnnsAnns added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR AI: Not Used AI was stated to not be used in this PR/Issue labels Jul 19, 2026

mguetschow mentioned this pull request Jul 19, 2026

net/unicoap: tracking: Unified and Modular CoAP Stack #21389

Open

20 tasks

crasbe added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation State: needs rebase State: The codebase was changed since the creation of the PR, making a rebase necessary labels Jul 19, 2026

carl-tud changed the title ~~unicoap: basic CoAP group communication support~~ net/unicoap: basic CoAP group communication support Jul 20, 2026

carl-tud requested changes Jul 20, 2026

View reviewed changes

crasbe reviewed Jul 20, 2026

View reviewed changes

carl-tud force-pushed the unicoap-p3 branch from 61de3ef to 0f6b43a Compare July 20, 2026 09:36

github-actions Bot added Area: doc Area: Documentation Area: tests Area: tests and testing framework Area: build system Area: Build system Area: examples Area: Example Applications Area: Kconfig Area: Kconfig integration labels Jul 20, 2026

elenaf9 force-pushed the unicoap-03-client-group-communication branch from 7d52f88 to 993cf29 Compare July 21, 2026 09:18

github-actions Bot removed the Area: tests Area: tests and testing framework label Jul 21, 2026

carl-tud deleted the branch RIOT-OS:pr/unicoap-client August 16, 2026 18:58

carl-tud closed this Aug 16, 2026

carl-tud reopened this Aug 16, 2026

unicoap: basic group communication support

d53226e

elenaf9 force-pushed the unicoap-03-client-group-communication branch from 993cf29 to d53226e Compare September 4, 2026 12:50

github-actions Bot removed Area: doc Area: Documentation Area: build system Area: Build system labels Sep 4, 2026

github-actions Bot removed Area: examples Area: Example Applications Area: Kconfig Area: Kconfig integration labels Sep 4, 2026

crasbe removed the State: needs rebase State: The codebase was changed since the creation of the PR, making a rebase necessary label Sep 4, 2026

mguetschow requested changes Sep 5, 2026

View reviewed changes

fixup! unicoap: basic group communication support

48cdf27

Apply suggestions from code review Co-authored-by: mguetschow <mikolai.guetschow@tu-dresden.de>

crasbe added the State: needs rebase State: The codebase was changed since the creation of the PR, making a rebase necessary label Sep 5, 2026

		if (!_is_multicast(memo)) {
		unicoap_event_cancel(&memo->super.exchange.timeout);

Uh oh!

Conversation

elenaf9 commented Jul 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Contribution description

Testing procedure

Issues/PRs references

Declaration of AI-Tools / LLMs usage:

Footnotes

Uh oh!

Uh oh!

Uh oh!

riot-ci commented Jul 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Murdock results

Artifacts

Uh oh!

carl-tud left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mguetschow commented Jul 20, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

elenaf9 commented Sep 4, 2026

Open TODOs

Open Questions:

Footnotes

Uh oh!

mguetschow left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mguetschow Sep 5, 2026

Choose a reason for hiding this comment

Uh oh!

elenaf9 Sep 5, 2026

Choose a reason for hiding this comment

Uh oh!

mguetschow Sep 5, 2026

Choose a reason for hiding this comment

Uh oh!

elenaf9 Sep 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

mguetschow Sep 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elenaf9 Sep 5, 2026

Choose a reason for hiding this comment

Uh oh!

mguetschow Sep 5, 2026

Choose a reason for hiding this comment

Uh oh!

elenaf9 Sep 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mguetschow Sep 5, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

elenaf9 commented Jul 19, 2026 •

edited

Loading

riot-ci commented Jul 19, 2026 •

edited

Loading

elenaf9 Sep 5, 2026 •

edited

Loading

mguetschow Sep 5, 2026 •

edited

Loading

elenaf9 Sep 5, 2026 •

edited

Loading