openthread-br: update to 2026.08.0, internal mDNS, configurable REST listen address

[LorbusChris]

📦 Package Details

Maintainer: @stintel

Description

Updates openthread-br to the 2026.08.0 release and switches to OpenThread's internal mDNS, addressing the mDNS/REST issues discussed in #29784.

1. Update to 2026.08.0. Re-pins to the release and drops the two patches upstream at this tag. The 2026.07.0 proxy rework made the legacy OTBR_SRP_ADVERTISING_PROXY / OTBR_DNSSD_DISCOVERY_PROXY / OTBR_DUA_ROUTING options fail configure, so they are dropped; vendor/product names are now required at startup and are set to OpenThread / BorderRouter, the same MeshCoP instance name earlier releases advertised, so an upgrade renames nothing.

2. Make the REST listen address configurable. The release defaults REST to 127.0.0.1, breaking remote clients like Home Assistant (Bump OpenThread Border Router and switch to internal mDNS implementation #29784 issue 1). Adds rest_listen_address / rest_listen_port proto options; unset keeps the loopback default.

3. Use OpenThread's internal mDNS (OTBR_MDNS=openthread, upstream's default since [mdns] change default to OT mDNS openthread/ot-br-posix#2996), dropping the mdnsd / mDNSResponder dependencies (Bump OpenThread Border Router and switch to internal mDNS implementation #29784 issue 2). This lets otbr-agent share a router with umdns without name contention: OT names its host after the Thread extended address (ot<ExtAddress>.local), umdns keeps <hostname>.local, and both bind :5353 via SO_REUSEADDR in either start order. Caveats: OT's mDNS serves only the backbone_network interface, and a unicast reply meant for one daemon can land on the other.

🧪 Run Testing Details

Builds clean in the OpenWrt SDK (x86_64, replicating the feed CI flow). umdns coexistence exercised against a simulated RCP (both daemons bound in either start order, services resolved by a third-party zeroconf browse), and the same update has since been running on a Turris Omnia alongside umdns with a Home Assistant Connect ZBT-2 RCP, commissioned into a Matter fabric.

test.sh exercises otbr-agent --version (the Makefile passes -DOTBR_VERSION, thanks @BKPepe) and ot-ctl -h — ot-ctl has no version option at this release (openthread/openthread#13424 missed the submodule pin by four days; the long-option segfault the probe surfaced is fixed here via openthread/openthread#13423).

Follow-ups stacked on this PR: #30096 (LuCI app separation), #30276 (RCP discovery, draft).

✅ Formalities

• I have reviewed the CONTRIBUTING.md file for detailed contributing guidelines.

[stintel]

As this has not even been build-tested, I am going to request changes here. This PR has the potential to completely break people's smart homes, so without runtime testing this is a 100% no go.

[LorbusChris]

As this has not even been build-tested, I am going to request changes here. This PR has the potential to completely break people's smart homes, so without runtime testing this is a 100% no go.

👍 I'll be doing testing on actual hardware soon - this also requires openwrt/luci#8871 and coordination between the two.

[stintel]

👍 I'll be doing testing on actual hardware soon - this also requires openwrt/luci#8871 and coordination between the two.

Thanks, appreciated. I'd be interested to know more about your setup and hardware. I had the idea of adding some kind of tested hardware matrix in the README.md.

[LorbusChris]

@stintel my first field test will be on a Turris Omnia NG (running the Turris OS flavour of OpenWrt) with a Home Assistant Connect ZBT-2.

[stintel]

@stintel my first field test will be on a Turris Omnia NG (running the Turris OS flavour of OpenWrt) with a Home Assistant Connect ZBT-2.

Great, that's completely different from my setup: 2x Olimex A64-OLinuXino with nRF52840 MDK USB Dongle in a dual-border-router setup with stateful packet filtering and conntrack state syncing with conntrackd and TREL between the 2. I have briefly been running with a 3rd border-router on a TP-Link EAP683-LR with the integrated CC2652, but the firmware of that CC2652 appeared to be unstable so it is currently disabled until I have time (and probably a 2nd device) to debug this properly.

[LorbusChris]

@stintel could you approve the "Test and Build" CI workflow? This should build now and I'm curious if anything else pops up.

[LorbusChris]

I'd also be happy to split the 3rd commit out into its own PR so the update can go in independently.

[stintel]

@stintel could you approve the "Test and Build" CI workflow? This should build now and I'm curious if anything else pops up.

Done

[stintel]

I'd also be happy to split the 3rd commit out into its own PR so the update can go in independently.

If it's not too much hassle, I think I would prefer that. I'd like to thoroughly review and test this PR myself before accepting it, so having the LuCI separation in a different PR would allow that to land earlier. Also regarding mDNSResponder vs OpenThread's internal mDNS support, I'm not sure. I think I'd prefer following upstream's default. We would then have to make sure we can't run another mDNS daemon when otbr-agent is running. I see your point about keeping mDNSResponder as default, but I guess we have to check how that works when someone also install umdns and/or avahi-daemon. Lastly, otbr-agent is the only consumer of mDNSResponder and @neheb suggested to drop mDNSResponder from tree entirely after landing my 2026.06 bump.

[LorbusChris]

Switched to OTBR_MDNS=openthread as you preferred — that also takes care of both blockers you mentioned on #29784 (the REST bind, and the proto handler's mdnsd check).

I tested it alongside umdns on a simulated RCP and they seem to get along fine: OT names its host ot<ExtAddress>.local rather than taking <hostname>.local, so there's nothing to fight over. Both bound 5353 in either start order, umdns kept announcing normally, and a zeroconf browse picked up _meshcop._udp and _trel._udp alongside umdns's own services.

One thing worth knowing: OT's mDNS only serves the single backbone_network interface, so a separate guest/IoT VLAN wouldn't see Thread records.

Also added a test.sh — with the release tag in PKG_VERSION the generic version check can't pass, since otbr-agent reports the CMake project version. And the LuCI removal is split out to #30096.

Hardware testing on a Turris Omnia NG + ZBT-2 next. Mind re-approving the build workflow?

[openwrt-ai]

Reviewed 3 new commits (fresh review, full PR diff). All three commit messages match their diffs.

Verified against upstream ot-br-posix at v2026.07.0 (ec16e396): the tag exists; both dropped patches are indeed upstream at that tag; OTBR_DUA_ROUTING is gone from etc/cmake/options.cmake; the "Only one Advertising Proxy can be enabled." FATAL_ERROR and the OT-core proxy defaults are as described; OTBR_MDNS=openthread is the upstream default and a valid value; --rest-listen-address / --rest-listen-port exist as required_argument long options; and the ot-ctl getopt_long() missing-terminator bug behind the -h choice in test.sh is real (-h exits 0 via PrintUsage(..., stdout, OT_EXIT_SUCCESS)).

Two things I'd look at before merge — one that blocks the CI job, and one that I think blocks the package at runtime; both are inline.

---

Generated by Claude Code

[TimB87]

I am just dropping my 2 cents here because its funny, I individually set down yesterday updating this package on my local install without knowing that this PR was up.

These are my locally made changes:

diff --git a/net/openthread-br/Makefile b/net/openthread-br/Makefile
index 9486685..d49e9ae 100644
--- a/net/openthread-br/Makefile
+++ b/net/openthread-br/Makefile
@@ -4,13 +4,13 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=openthread-br
-PKG_SOURCE_DATE:=2025-06-12
-PKG_SOURCE_VERSION:=2f3c799c7463c8f674754e65c53f78bc0bbcbd58
-PKG_RELEASE:=2
+PKG_SOURCE_DATE:=2026-06-25
+PKG_SOURCE_VERSION:=ec16e396382b4559e70a2c6fdeecb7d596a5e915
+PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL=https://github.com/openthread/ot-br-posix.git
-PKG_MIRROR_HASH:=fae1c7c88102f88bac32f8ee25e044b9a8781eef6b9acef39388e1e11a44a195
+PKG_MIRROR_HASH:=d19a2ea6d01d66151f769e6d23450a23d5802c5a9adf3b37fe4938fb3acf63a3
 
 PKG_MAINTAINER:=Stijn Tintel <stijn@linux-ipv6.be>
 PKG_LICENSE:=BSD-3-Clause
@@ -41,9 +41,7 @@ define Package/openthread-br
 	+libreadline \
 	+libstdcpp \
 	+libubox \
-	+libubus \
-	+mdnsd \
-	+mdnsresponder
+	+libubus
 endef
 
 define Package/openthread-br/description
@@ -63,13 +61,15 @@ CMAKE_OPTIONS += \
 	-DOT_TARGET_OPENWRT=ON \
 	-DOTBR_BACKBONE_ROUTER=ON \
 	-DOTBR_BORDER_ROUTING=ON \
-	-DOTBR_DNSSD_DISCOVERY_PROXY=ON \
+  -DOTBR_DNSSD_DISCOVERY_PROXY=OFF \
+	-DOTBR_OT_DISCOVERY_PROXY=ON \
 	-DOTBR_DUA_ROUTING=ON \
-	-DOTBR_MDNS=mDNSResponder \
+  -DOTBR_MDNS=openthread \
 	-DOTBR_NAT64=OFF \
 	-DOTBR_OPENWRT=ON \
 	-DOTBR_REST=ON \
-	-DOTBR_SRP_ADVERTISING_PROXY=ON \
+	-DOTBR_SRP_ADVERTISING_PROXY=OFF \
+	-DOTBR_OT_SRP_ADV_PROXY=ON \
 	-DOTBR_SRP_SERVER_AUTO_ENABLE=ON \
 	-DOTBR_TREL=ON
 
diff --git a/net/openthread-br/patches/101-rest-Permit-to-externally-provide-cJSON-library.patch b/net/openthread-br/patches/101-rest-Permit-to-externally-provide-cJSON-library.patch
deleted file mode 100644
index 812978c..0000000
--- a/net/openthread-br/patches/101-rest-Permit-to-externally-provide-cJSON-library.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 59c389a91cfe91eebed9c36887fa2a3eca4cbd6f Mon Sep 17 00:00:00 2001
-From: Christian Marangi <ansuelsmth@gmail.com>
-Date: Mon, 24 Nov 2025 18:53:28 +0100
-Subject: [PATCH] [rest] Permit to externally provide cJSON library
-
-Permit to externally provide cJSON library if found with PKGConfig.
-
-Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
----
- src/rest/CMakeLists.txt    | 12 +++++++++++-
- third_party/CMakeLists.txt |  5 ++++-
- 2 files changed, 15 insertions(+), 2 deletions(-)
-
---- a/src/rest/CMakeLists.txt
-+++ b/src/rest/CMakeLists.txt
-@@ -36,11 +36,22 @@ add_library(otbr-rest
-     response.cpp
- )
- 
-+if (CJSON_FOUND)
-+    set(CJSON_LIB_TARGETS ${CJSON_LINK_LIBRARIES})
-+else()
-+    set(CJSON_LIB_TARGETS cjson)
-+endif()
-+
-+target_include_directories(otbr-rest
-+    PRIVATE
-+        ${CJSON_INCLUDE_DIRS}
-+)
-+
- target_link_libraries(otbr-rest
-     PUBLIC
-         http_parser
-     PRIVATE
--        cjson
-+        ${CJSON_LIB_TARGETS}
-         otbr-config
-         otbr-utils
-         openthread-ftd
---- a/third_party/CMakeLists.txt
-+++ b/third_party/CMakeLists.txt
-@@ -28,6 +28,13 @@
- 
- add_subdirectory(openthread)
- if(OTBR_REST)
--    add_subdirectory(cJSON)
-+    pkg_check_modules(CJSON libcjson)
-+    if (CJSON_FOUND)
-+        set(CJSON_FOUND ${CJSON_FOUND} PARENT_SCOPE)
-+        set(CJSON_INCLUDE_DIRS ${CJSON_INCLUDE_DIRS} PARENT_SCOPE)
-+        set(CJSON_LINK_LIBRARIES ${CJSON_LINK_LIBRARIES} PARENT_SCOPE)
-+    else()
-+        add_subdirectory(cJSON)
-+    endif()
-     add_subdirectory(http-parser)
- endif()
diff --git a/net/openthread-br/patches/102-openwrt-fix-LuCI-icons.patch b/net/openthread-br/patches/102-openwrt-fix-LuCI-icons.patch
deleted file mode 100644
index 701ae0f..0000000
--- a/net/openthread-br/patches/102-openwrt-fix-LuCI-icons.patch
+++ /dev/null
@@ -1,68 +0,0 @@
-From 4b09d856fd3d82bfb6707d889fb40f981945a6a2 Mon Sep 17 00:00:00 2001
-From: Stijn Tintel <stijn@linux-ipv6.be>
-Date: Wed, 7 Jan 2026 00:20:04 +0200
-Subject: [PATCH] [openwrt] fix LuCI icons (#3178)
-
-The PNG icons in LuCI have been replaced with SVG icons.
-
-Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
----
- src/openwrt/view/admin_thread/thread_overview.htm | 10 +++++-----
- src/openwrt/view/admin_thread/thread_scan.htm     | 12 ++++++------
- 2 files changed, 11 insertions(+), 11 deletions(-)
-
---- a/src/openwrt/view/admin_thread/thread_overview.htm
-+++ b/src/openwrt/view/admin_thread/thread_overview.htm
-@@ -32,7 +32,7 @@
- 		<!-- physical device -->
- 		<div class="tr cbi-rowstyle-2">
- 			<div class="td col-1 center middle">
--				<span class="ifacebadge"><img src="<%=resource .. "/icons/wifi.png"%>" id="wpan0" /> <%=threadget("interfacename").InterfaceName%></span>
-+				<span class="ifacebadge"><img src="<%=resource .. "/icons/wifi.svg"%>" id="wpan0" /> <%=threadget("interfacename").InterfaceName%></span>
- 			</div>
- 			<div class="td col-7 left middle">
- 				<big><strong><%:Generic MAC 802.15.4 Thread%></strong></big><br />
-@@ -164,13 +164,13 @@
- 		var scale = percent_thread_signal(info);
- 
- 		if (scale == 0)
--			icon = "<%=resource%>/icons/signal-0.png";
-+			icon = "<%=resource%>/icons/signal-000.svg";
- 		else if (scale == 30)
--			icon = "<%=resource%>/icons/signal-25-50.png";
-+			icon = "<%=resource%>/icons/signal-025-050.svg";
- 		else if (scale == 50)
--			icon = "<%=resource%>/icons/signal-50-75.png";
-+			icon = "<%=resource%>/icons/signal-050-075.svg";
- 		else
--			icon = "<%=resource%>/icons/signal-75-100.png";
-+			icon = "<%=resource%>/icons/signal-075-100.svg";
- 
- 		return icon;
- 	}
---- a/src/openwrt/view/admin_thread/thread_scan.htm
-+++ b/src/openwrt/view/admin_thread/thread_scan.htm
-@@ -17,17 +17,17 @@
- 		end
- 
- 		if info.NetworkName == nil then
--			icon = resource .. "/icons/signal-none.png"
-+			icon = resource .. "/icons/signal-none.svg"
- 		elseif scale < 15 then
--			icon = resource .. "/icons/signal-0.png"
-+			icon = resource .. "/icons/signal-000.svg"
- 		elseif scale < 35 then
--			icon = resource .. "/icons/signal-0-25.png"
-+			icon = resource .. "/icons/signal-000-025.svg"
- 		elseif scale < 55 then
--			icon = resource .. "/icons/signal-25-50.png"
-+			icon = resource .. "/icons/signal-025-050.svg"
- 		elseif scale < 75 then
--			icon = resource .. "/icons/signal-50-75.png"
-+			icon = resource .. "/icons/signal-050-075.svg"
- 		else
--			icon = resource .. "/icons/signal-75-100.png"
-+			icon = resource .. "/icons/signal-075-100.svg"
- 		end
- 
- 		return icon

It's clear Chris is further than I am. But I have been running this on my system last night until now and besides a few mistakes I made along the way, the update itself works.

So take that for a +1 for "it won't break peoples smart homes".

Edit:
As for my setup over here, I have an SLZB-06M with Thread firmware running, using socat on openwrt to create a socket that otbr-agent can connect to.

[openwrt-ai]

Re-reviewed after the force-push. Diffed c4254e94 (my last review) against 6e05e4cd: three files in net/openthread-br/ — the re-pin to 2026.08.0 with a new PKG_MIRROR_HASH, -DOTBR_VERSION=$(PKG_VERSION), test-version.sh deleted, and test.sh's comments rewritten to match. All three commit messages still match their diffs; PKG_RELEASE correctly stays at 1 for the version bump.

The interesting change is dropping the override script, so I checked whether the generic version check actually passes without it, end to end:

• v2026.08.0 exists upstream (337711e7, via git ls-remote), and 2026.08.0 is the newest tag on the repo.
• OTBR_VERSION is a real cache variable, not a no-op: if(NOT OTBR_VERSION) at CMakeLists.txt:72 guards the fallback, and the value lands in OTBR_PACKAGE_VERSION, which --version prints verbatim. So otbr-agent --version emits exactly 2026.08.0.
• The harness strips the release suffix before matching (PKG_VERSION="${PKG_VERSION%-[!-]*}", test_entrypoint.sh:305-306), so it greps for 2026.08.0, not 2026.08.0-r1 — the match holds.
• ot-ctl still won't report a version, but that is not a failure: the job only fails when every executable misses it ([ "$exec_checked" -eq "$version_missing" ], test_entrypoint.sh:247-255); a partial miss is a warn. Expect one 1/2 executables are missing version 2026.08.0 line in the log, nothing more.
• That same code path is why the commit message's "as it already does on master" is accurate rather than rhetorical: on master neither binary reports the packaged version, so exec_checked == version_missing and the check genuinely fails there today.
• luci-app-openthread installs no executables, so exec_checked is 0 and the block is skipped entirely — losing the luci-app-openthread) arm from test-version.sh costs nothing, and test.sh still carries its own arm. No introduce-then-remove pair is left in the series either; test-version.sh never appears in the final three commits.

CI on 6e05e4cd: the three FormalityCheck runs are green. Feeds Package Test Build has not run on this head (it needs maintainer approval), so there is nothing to report from logs — worth an eye when it does, since this is the first head where the generic version check runs unmasked.

Nothing blocking. One nit inline.

---

Generated by Claude Code

[openwrt-ai]

Re-reviewed after the force-push. Diffed 6e05e4cd (my last review) against 2c803bcf: one file, net/openthread-br/README.md, +17/-4. No rebase this time — the three commits are byte-identical to df882011 / 6875a576 / 6e05e4cd apart from the README hunks, and all three commit messages still match their diffs.

Both hunks are follow-ups to the previous round, and each lands in the commit that owns the change it documents rather than as a fixup on top:

• ### Version string (lines 41-50) goes into commit 1, which is where -DOTBR_VERSION=$(PKG_VERSION) is added. It records the two things that were only implicit before — that the fallback is the CMake project version because the repacked tarball has no git dir for git describe, and that the CI version check depends on this option — so the line can't be dropped later as looking redundant with PKG_VERSION. That matches the ### Vendor and product name section immediately above it, so all three of this PR's packaging decisions are now recorded in the file that exists to hold them.
• The required/optional paragraph goes into commit 2, which is where rest_listen_address / rest_listen_port are introduced. Worth noting it also corrects a pre-existing error: the old text said "Prefix, verbose, rest_listen_address and rest_listen_port are optional. Everything else is required", which made dataset look mandatory when the handler only touches it under [ -n "$dataset" ].

I checked the new claims against the handler at this head and against the harness rather than taking them as given:

• The three required options and the "no device" case are exactly what proto_openthread_setup() enforces — see the inline comment for the line references.
• [REST Server](#rest-server) resolves: the target heading ### REST Server is at README.md:70.
• "dropping this option would make the package fail it again" holds. The generic check only fails when every probed executable misses the string ([ "$exec_checked" -eq "$version_missing" ], test_entrypoint.sh:247-255) — without OTBR_VERSION, otbr-agent prints the project version and ot-ctl prints none, so both miss and the job fails; with it, otbr-agent matches and the ot-ctl miss is only a warn.

CI on 2c803bcf: the three FormalityCheck runs are green. Feeds Package Test Build has not run on this head, so there is nothing to report from logs; it is still worth a look when it does, since this head and its predecessor are the first without test-version.sh masking the generic version check.

Nothing blocking. One nit inline, presentation only.

---

Generated by Claude Code

[openwrt-ai]

Reviewed 3 new commits; no new issues found.

Diffed 2c803bcf (my last review) against 233cfaa7: one file, net/openthread-br/README.md, +4/-4 — exactly the suggestion from the previous round. The two -- separators in the required/optional paragraph became —, matching line 90 in the same file, and the tail rewrapped so the last two lines are no longer ragged against the file's ~79-column wrap. No ASCII double-hyphen is left anywhere in the file, so the fix is complete rather than local.

The change is folded into commit 2 (caacf174), which is the commit that introduces that paragraph together with rest_listen_address / rest_listen_port — not added as a fixup on top, so there is no introduce-then-fix pair in the series. Commit 1 is unchanged (07cd2dc8, same SHA as before), and commit 3 (233cfaa7) differs from 2c803bcf only in the blob it carries forward; git show --format=%B on both is byte-identical. All three commit messages still match their diffs, and PKG_RELEASE:=1 remains correct for the version bump.

Nothing in this delta touches the two threads still open with @BKPepe (the PKG_SOURCE_VERSION:=v$(PKG_VERSION) pin, tracked upstream in openthread/ot-br-posix#3496 / #3497, and the MeshCoP instance name question on README.md:35). Both are maintainer calls rather than defects I can adjudicate, so I have nothing to add there.

CI on 233cfaa7: the three FormalityCheck runs are green. Feeds Package Test Build has not run on this head, so there is nothing to report from logs; still worth a look when it does, since this head and its two predecessors are the first without test-version.sh masking the generic version check.

---

Generated by Claude Code

[LorbusChris]

@stintel anything else I can do here? Upstream has now dropped the Luci app, so with the next release I'd have to include #30096 here again too. I've been using this package (plus additional downstream patches) and haven't had any problems.