OTNS integration by gmarcosb · Pull Request #43478 · project-chip/connectedhomeip

gmarcosb · 2026-03-04T21:57:48Z

Summary

Continue work from #42841 to get OTNS to work such that chip-tool can provision directly through OTNS

To build, use:

source scripts/activate.sh; BUILD_VARIANT=no-shell-clang-boringssl && ./scripts/run_in_build_env.sh \
                     "./scripts/build/build_examples.py \
                        --target linux-x64-all-clusters-no-wifi-no-ble-openthread-endpoint-otns-clang \
                        build
                     "

To run the app as an external node in OTNS (requires openthread/ot-ns#755), after starting otns, run:

'out/linux-x64-all-clusters-no-wifi-openthread-endpoint-otns-clang/chip-all-clusters-app' '--thread-args=3' '--thread-args=/tmp/otns/socket_dispatcher_0' '--thread-args=20242025'

The next step is to get chip-tool to build:

source scripts/activate.sh; BUILD_VARIANT=no-shell-clang-boringssl && ./scripts/run_in_build_env.sh \
                     "./scripts/build/build_examples.py \
                        --target linux-x64-all-clusters-no-wifi-no-ble-openthread-endpoint-otns-clang \
                        --target linux-x64-chip-tool-no-wifi-no-ble-openthread-endpoint-otns-clang \
                        build
                     "

And finally, the commissioning test to pass using OTNS:

PATH=$PWD/objdir-clone:$PATH ./scripts/run_in_build_env.sh                   "./scripts/tests/run_test_suite.py \
                     --find-path $PWD/objdir-clone \
                     --find-path $PWD/scripts \
                     --runner chip_tool_python \
                     --target TestOperationalState \
                     run \
                     --iterations 1 \
                     --test-timeout-seconds 120 \
                     --tool-path chip-tool:./out/linux-x64-chip-toolno-wifi-no-ble-openthread-endpoint-otns/chip-tool \
                     --tool-path otns:./third_party/ot-ns/repo/cmd/otns/otns \
                     --all-clusters-app ./out/linux-x64-all-clusters-no-wifi-no-ble-openthread-endpoint-otns-clang/chip-all-clusters-app \
                     --commissioning-method otns-meshcop \
                  "

Related issues

Testing

Readability checklist

The checklist below will help the reviewer finish PR review in time and keep the
code readable:

PR title is
descriptive
Apply the
“When in Rome…”
rule (coding style)
PR size is short
Try to avoid "squashing" and "force-update" in commit history
CI time didn't increase

See: Pull Request Guidelines

This reverts commit d8ab9ded4324abb13a29aa318ce18b2216532c7e.

…hip-tool can provision directly through OTNS

gmarcosb · 2026-03-04T21:59:56Z

    "repo/src/library/udp_proxy.cpp",
  ]
-  deps = [ ":ot_commissioner_mbedtls" ]
+  if (chip_enable_otns) {


@bukepo I am having a hard time figuring out how to get chip-tool to compile with the third_party/openthread/platforms:libopenthread-platform dep, as we run into duplicate symbols for mbedtls

Is my dependency wrong, i.e. does chip-tool not need the things in chip_enable_otns (in examples/platform/linux/BUILD.gn)?

Think I figured it out... I guess this is for off-mesh, and my goal is to get chip-tool to be on-mesh so that we have 0 dependency on external network & are fully within OTNS

So I think I want to use https://github.com/openthread/openthread/blob/main/include/openthread/commissioner.h instead?

gemini-code-assist

Code Review

This pull request integrates OTNS (OpenThread Network Simulator) into the build and test system. The changes are extensive, touching build scripts, application options, platform code, and test infrastructure. The core idea is to allow running and testing Matter-over-Thread devices in a simulated network environment provided by OTNS. While the overall direction is good, I've found several critical issues in the Python test infrastructure code that will likely cause tests to fail, particularly around how command-line arguments are constructed for subprocesses. There are also some minor issues with logging levels and code duplication that should be addressed. One comment has been enhanced with a reference to a code duplication rule.

gemini-code-assist · 2026-03-04T22:01:40Z

+    def apply_args(self, process: SubprocessInfo) -> SubprocessInfo:
+        return process.with_args("--thread-args=2")


The with_args method replaces all existing arguments on the SubprocessInfo object. This implementation discards any arguments that were previously set on the process object, which will lead to incorrect behavior. The arguments should be appended instead of replaced.

Suggested change

def apply_args(self, process: SubprocessInfo) -> SubprocessInfo:

return process.with_args("--thread-args=2")

def apply_args(self, process: SubprocessInfo) -> SubprocessInfo:

return process.with_args(*process.args, "--thread-args=2")

gemini-code-assist · 2026-03-04T22:01:41Z

+    def apply_pairing_args(self, process: SubprocessInfo) -> SubprocessInfo:
+        if self._meshcop:
+            return process.with_args("pairing", "thread-meshcop", "--thread-ba-host", self.get_border_agent_host(), "--thread-ba-port", str(self.get_border_agent_port()))
+        else:
+            return process.with_args("pairing", "code-thread")


The with_args method replaces all existing arguments. When this method is called from test_definition.py, the process object already contains necessary arguments like node ID and dataset. This implementation discards them, resulting in an incomplete or incorrect pairing command. The logic for constructing the pairing command needs to be revised to preserve all necessary arguments.

gemini-code-assist · 2026-03-04T22:01:41Z

+    def apply_args(self, process: SubprocessInfo) -> SubprocessInfo:
+        socket = self._otns.get_otns_socket()
+        process = process.with_args("--thread-args=2")
+        process = process.with_args(f"--thread-args={socket}")
+        return process.with_args(f"--thread-args={ThreadOtns.RANDOM_SEED}")


The with_args method replaces existing arguments, but it is called multiple times here. Each call overwrites the arguments from the previous one, and also discards any arguments the process object already had. As a result, only the last argument (--thread-args={ThreadOtns.RANDOM_SEED}) will be passed. All arguments should be appended to the existing ones.

Suggested change

def apply_args(self, process: SubprocessInfo) -> SubprocessInfo:

socket = self._otns.get_otns_socket()

process = process.with_args("--thread-args=2")

process = process.with_args(f"--thread-args={socket}")

return process.with_args(f"--thread-args={ThreadOtns.RANDOM_SEED}")

def apply_args(self, process: SubprocessInfo) -> SubprocessInfo:

socket = self._otns.get_otns_socket()

return process.with_args(*process.args, "--thread-args=2", f"--thread-args={socket}", f"--thread-args={ThreadOtns.RANDOM_SEED}")

gemini-code-assist · 2026-03-04T22:01:41Z

+    def apply_pairing_args(self, process: SubprocessInfo) -> SubprocessInfo:
+        return process.with_args("pairing", "thread-meshcop", "--thread-ba-host", self.get_border_agent_host(), "--thread-ba-port", str(self.get_border_agent_port()))


The ThreadOtns class does not implement the get_border_agent_host and get_border_agent_port methods. Calling them here will result in a runtime AttributeError. These methods seem to have been copied from the ThreadBorderRouter class and need to be correctly implemented for ThreadOtns.

gemini-code-assist · 2026-03-04T22:01:41Z

+    Microseconds64 GetMonotonicMicroseconds64() override { return Microseconds64(otPlatTimeGet()); }
+    Milliseconds64 GetMonotonicMilliseconds64() override { return std::chrono::duration_cast<Milliseconds64>(Microseconds64(otPlatTimeGet())); }
+
+    CHIP_ERROR GetClock_RealTime(Microseconds64 & aCurTime) override
+    {
+        aCurTime = Microseconds64(otPlatTimeGet());
+        return CHIP_NO_ERROR;
+    }
+    CHIP_ERROR GetClock_RealTimeMS(Milliseconds64 & aCurTime) override
+    {
+        aCurTime = std::chrono::duration_cast<Milliseconds64>(Microseconds64(otPlatTimeGet()));
+        return CHIP_NO_ERROR;
+    }


There's some code duplication in the MockClock implementation. The same call to otPlatTimeGet() and the same duration_cast logic are repeated across multiple methods. You can improve readability and maintainability by reusing the GetMonotonic... methods within the GetClock_RealTime... methods.

Microseconds64 GetMonotonicMicroseconds64() override { return Microseconds64(otPlatTimeGet()); } Milliseconds64 GetMonotonicMilliseconds64() override { return std::chrono::duration_cast<Milliseconds64>(GetMonotonicMicroseconds64()); } CHIP_ERROR GetClock_RealTime(Microseconds64 & aCurTime) override { aCurTime = GetMonotonicMicroseconds64(); return CHIP_NO_ERROR; } CHIP_ERROR GetClock_RealTimeMS(Milliseconds64 & aCurTime) override { aCurTime = GetMonotonicMilliseconds64(); return CHIP_NO_ERROR; }

References

To improve maintainability and reduce code duplication, extract common logic from similar methods into private helper functions.

gemini-code-assist · 2026-03-04T22:01:41Z

                      stdin: IO[Any] | None = None) -> tuple[subprocess.Popen[bytes], LogPipe, LogPipe]:
        cmd = subproc.to_cmd()
-        log.info('RunSubprocess starting application %s', " ".join(cmd))
+        log.error('RunSubprocess starting application %s', " ".join(cmd))


This log message appears to have been changed to error level, likely for debugging. This should be reverted to info or debug to avoid flooding the logs with errors during normal test execution.

Suggested change

log.error('RunSubprocess starting application %s', " ".join(cmd))

log.info('RunSubprocess starting application %s', " ".join(cmd))

gemini-code-assist · 2026-03-04T22:01:41Z

+                log.error("Pairing command: %s", shlex.join(pairing_cmd.to_cmd()))
+                log.error("Testcase command: %s", shlex.join(test_cmd.to_cmd()))


These log messages appear to have been changed to error level, likely for debugging purposes. Please consider changing them to a more appropriate level, such as info or debug, to avoid unnecessary error output during test runs.

Suggested change

log.error("Pairing command: %s", shlex.join(pairing_cmd.to_cmd()))

log.error("Testcase command: %s", shlex.join(test_cmd.to_cmd()))

log.info("Pairing command: %s", shlex.join(pairing_cmd.to_cmd()))

log.info("Testcase command: %s", shlex.join(test_cmd.to_cmd()))

gmarcosb added 4 commits March 4, 2026 12:23

Fix chip-tool build breakage caused by openthread build failure

71bd792

Revert "Fix chip-tool build breakage caused by openthread build failure"

749ce72

This reverts commit d8ab9ded4324abb13a29aa318ce18b2216532c7e.

Fix chip-tool build breakage caused by openthread build failure

741eb1b

Continue work from project-chip#42841 to get OTNS to work such that c…

9e6ab8a

…hip-tool can provision directly through OTNS

gmarcosb requested a review from bukepo March 4, 2026 21:58

github-actions Bot added tools examples scripts system platform linux controller github workflows tests labels Mar 4, 2026

gmarcosb commented Mar 4, 2026

View reviewed changes

gemini-code-assist Bot reviewed Mar 4, 2026

View reviewed changes

mergify Bot added the conflict label May 22, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OTNS integration#43478

OTNS integration#43478
gmarcosb wants to merge 4 commits into
project-chip:masterfrom
gmarcosb:openthread

gmarcosb commented Mar 4, 2026 •

edited

Loading

Uh oh!

gmarcosb Mar 4, 2026 •

edited

Loading

Uh oh!

gmarcosb Mar 4, 2026

Uh oh!

gemini-code-assist Bot left a comment

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

		def apply_args(self, process: SubprocessInfo) -> SubprocessInfo:
		return process.with_args("--thread-args=2")

		def apply_pairing_args(self, process: SubprocessInfo) -> SubprocessInfo:
		return process.with_args("pairing", "thread-meshcop", "--thread-ba-host", self.get_border_agent_host(), "--thread-ba-port", str(self.get_border_agent_port()))

	log.error('RunSubprocess starting application %s', " ".join(cmd))
	log.info('RunSubprocess starting application %s', " ".join(cmd))

		log.error("Pairing command: %s", shlex.join(pairing_cmd.to_cmd()))
		log.error("Testcase command: %s", shlex.join(test_cmd.to_cmd()))

Conversation

gmarcosb commented Mar 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Related issues

Testing

Readability checklist

Uh oh!

gmarcosb Mar 4, 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!

gmarcosb Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist Bot Mar 4, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

gmarcosb commented Mar 4, 2026 •

edited

Loading

gmarcosb Mar 4, 2026 •

edited

Loading