TC-SC-5.3 (sending a group message, proved by what it changed)

[Apollon77]

Adds the certification case TC-SC-5.3, which the group-messaging block had been blocked on. It is the mirror of TC-SC-6.1: the same four setup steps — an ACL entry admitting the group, a key set, the GroupKeyMap binding, AddGroup — and then, where 6.1 reads that state back over unicast, 5.3 sends a group message through it. Those four steps are now one module both cases use, so the two cannot drift.

The controller can address a group now

controllers.dut.group(id) returns a CertGroupApi with defineKeySet and an invoke that takes no endpoint — a group command's path names only the cluster and command, and the endpoints come from the group's own membership. matter.js resolves the group as a peer whose node id encodes it (NodeId.fromGroupId); chip-tool takes the same thing as a destination id of 0xFFFF'FFFF'FFFF'0000 | groupId, and needs three groupsettings commands of its own first — without them its GroupDataProviderImpl refuses the send outright.

Four things the plan does not say, each of which fails silently

• The sender needs the key too. Writing the key set to the device is half of it: the controller encrypts the message, so it must hold the key as well. That is what the plan means by "DUT generates a random key".
• It has to go on the fabric the sending path resolves. The adapter's own Fabric handle is a different object for the same fabric index than SessionManager.fabricFor returns, and group state written on the adapter's copy is invisible to the sender. The symptom is No group key set found for groupId from a controller that just provisioned one.
• The ACL entry needs Manage, not Operate. Groups.AddGroup is a Manage command. With Operate the message arrives, decrypts and dispatches — and does nothing, because a group message is unacknowledged and nothing reports the refusal. It reads exactly like a multicast that never arrived.
• Both groups must be in the GroupKeyMap. AddGroup answers UNSUPPORTED_ACCESS for a group the fabric's map does not name (Application Clusters § 1.3.7.1), so a case adding group 2 through group 1 binds both.

All four are written up in the certification AGENTS.md so the next case in this block does not rediscover them.

What step 5 proves

The plan asks for four things and the sender's own log now carries all four:

• The multicast address is not shape-matched. The DUT's membership line names the group, the fabric and the address together, so the address is recomputed from that fabric id and group id and compared byte for byte — which also establishes the destination is GroupID 1.
• The port comes from the message's own destination field (see the protocol change below).
• The session is a group one: the sender's tag renders •group#…. That is the sender saying which kind of session it used, not a read of the packet's DSIZ field — which is why the step's expected outcome says so rather than claiming DSIZ directly. On a chip device the receiver does better: it names the group id it read off the packet.
• And the arrival, three ways, because the first is what makes the last mean anything: the device does not hold group 2 beforehand; its own log shows it dispatching the AddGroup with the group and name the message carried; and only then does a unicast ViewGroup(2) answer with them. That dispatch line is also the step's synchronisation — an unacknowledged multicast orders nothing against the unicast read that follows it.

On chip-tool, which logs the group it sent to and nothing more, the address-and-port half records unverified with that reason rather than passing; the effect check still runs.

Steps 6 and 7 stay not-applicable: they need the Groupcast cluster, which neither test harness has.

One protocol change

GroupSession.destination renders [<address>]:<port> and the group invoke's diagnostic uses it. Before, the line printed the address alone, so "verify the UDP port is 5540" had no observable evidence — and a group send's destination is arguably incomplete without it. Unit-tested; CHANGELOG entry under @matter/protocol.

Verification

Repository root:

npm run build          exit 0
npm run format-verify  exit 0
npm run lint           exit 0
npm test               exit 0

Certification suites (not covered by the root npm test):

npm --prefix support/chip-testing run test-cert-framework -- --no-pull   exit 0
npx matter-test --spec="test/cert/*.test.ts" --report                    exit 0

TC-SC-5.3 passes on all four matrix legs (matter.js and chip-tool controllers × matter.js and chip device flavors), and TC-SC-6.1 passes unchanged, which is what makes the shared-setup extraction safe.

A review finding that turned out to be live

The first version of step 5 proved arrival only by the device holding group 2 afterwards, with nothing establishing it had not held it before. A chip device keeps its state on disk between runs, so the chip legs had been passing on a group a previous run left behind. With the absence check added they failed, and the reason they pass now is that the message really is dispatched — which the device's own log line, added for the same reason, states directly.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Adds TC-SC-5.3 groupcast certification coverage and shared group setup infrastructure.

Changes:

• Adds group-addressed controller APIs for matter.js and chip-tool.
• Shares setup logic between TC-SC-5.3 and TC-SC-6.1.
• Logs and tests group destinations with address and port.

Reviewed changes

Copilot reviewed 17 out of 17 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
CHANGELOG.md	Records destination logging enhancement.
packages/protocol/src/action/client/ClientInteraction.ts	Logs group session destinations.
packages/protocol/src/session/GroupSession.ts	Formats multicast address and port.
packages/protocol/test/session/SecureSessionTest.ts	Tests destination formatting.
packages/testing/src/chip/cert/controller-adapter.ts	Defines group controller APIs.
packages/testing/src/chip/index.ts	Exports new group types.
support/chip-testing/src/cert/ChipToolControllerAdapter.ts	Implements chip-tool group sends.
support/chip-testing/src/cert/InProcessControllerAdapter.ts	Implements in-process group sends.
support/chip-testing/test/cert/AGENTS.md	Documents groupcast certification behavior.
support/chip-testing/test/cert/TC-SC-5.3.test.ts	Adds TC-SC-5.3.
support/chip-testing/test/cert/TC-SC-6.1.test.ts	Uses shared group setup.
support/chip-testing/test/cert/tc-group-support.ts	Provides shared group helpers.
support/chip-testing/test/cert-framework/cert-test.test.ts	Updates adapter stubs.
support/chip-testing/test/cert-framework/controller-adapter.test.ts	Updates adapter fixture.
support/chip-testing/test/cert-framework/tc-dd-support.test.ts	Updates adapter fixtures.
support/chip-testing/test/cert-framework/tc-idm-4.1-support.test.ts	Updates adapter fixture.
support/chip-testing/test/cert-framework/tc-support.test.ts	Updates adapter fixture.

Suppressed comments (4)

support/chip-testing/test/cert/TC-SC-5.3.test.ts:76

• The unicast ViewGroup is issued immediately after an unacknowledged UDP groupcast. Completion of group(...).invoke() only confirms the datagram was sent; it does not order remote processing against this separate unicast exchange, so the read can overtake the multicast and make this certification step flaky. Wait for the receiver effect (for example, poll ViewGroup within a bounded timeout) before declaring failure.

    const response = await node.invoke(GROUPS.name, "viewGroup", { groupId: SECOND_GROUP.id }, GROUPS_ENDPOINT);

support/chip-testing/test/cert/TC-SC-5.3.test.ts:80

• This success condition ignores groupName, although step 5 explicitly requires GroupTwo. A command that drops or corrupts that field still passes as long as group 2 exists. Validate the returned name with the same feature-aware rule used by TC-SC-6.1 (GroupTwo, or empty only when GroupNames is unsupported).

    const arrived = Number(status) === 0 && Number(groupId) === SECOND_GROUP.id;

support/chip-testing/test/cert/TC-SC-5.3.test.ts:225

• The step label says EP0, but addGroupStep invokes the Groups cluster on GROUPS_ENDPOINT, which is endpoint 1. Correct the label so certification output describes the command that was actually sent.

        'DUT sends AddGroup Command to TH on EP0 with GroupID 1 and GroupName "GroupOne"',

support/chip-testing/test/cert/TC-SC-5.3.test.ts:97

• This branch is unreachable: when arrived is false, the second recordAll check has verdict fail, and recordAll throws before execution reaches this if. Remove the dead block; its alternate error message can never be reported.

    if (!arrived) {
        throw new CertCheckFailedError(
            `the TH does not hold group ${SECOND_GROUP.id} after the groupcast: ${describeValue(response)}`,
        );
    }

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[Copilot]

Pull request overview

Copilot reviewed 17 out of 17 changed files in this pull request and generated 3 comments.

Suppressed comments (2)

support/chip-testing/test/cert/AGENTS.md:2391

• The quoted chip log text does not match the sequence the test actually accepts: DISPATCH_LINES waits for Processing group command for Endpoint=1 ..., not Received command for .... Use the real diagnostic wording so future pattern maintenance starts from the evidence this test consumes.

`ProtocolService Invoke «` line, and chip prints `Received command for Endpoint=1 Cluster=0x0000_0004
Command=0x0000_0000`.

support/chip-testing/test/cert/TC-SC-5.3.test.ts:300

• Use “an” before “AddGroup.”

        "DUT sends a AddGroup Command to the Groups cluster with the GroupID field set to 2 and the GroupName set " +