Bump OpenThread Border Router and switch to internal mDNS implementation by stintel · Pull Request #29784 · openwrt/packages

stintel · 2026-06-19T18:42:29Z

📦 Package Details

Maintainer: me

Description:
Bump OpenThread Border Router and switch to internal mDNS implementation

🧪 Run Testing Details

OpenWrt Version: OpenWrt master r34992-0d7add7433
OpenWrt Target/Subtarget: sunxi/cortexa53
OpenWrt Device: Olimex A64-Olinuxino-eMMC

✅ Formalities

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

BKPepe · 2026-06-20T11:31:46Z

+#!/bin/sh
+
+case "$1" in
+luci-app-openthread)


This luci-app should moved to the LuCI repo. Ideally those all files related to LuCI in openthread repository should be upstreamed.

That's not in scope for a version bump PR.

I understand this isn't exactly within the scope of this specific pull request. However, when openthread-br (#19218) was added, no issue was created for decoupling the LuCI files, and I just noticed this 3 years later. If we just say it's out of scope for the PR, then yes, you are absolutely right about that, which is why I created these issues:

Feature Request: Migrate OpenWrt LuCI app to the official OpenWrt LuCI repository openthread/ot-br-posix#3431

openthread-br: Decouple LuCI package from this repository #29791

So that it can actually be resolved properly and once and for all. :)

BKPepe · 2026-06-20T11:32:51Z

 	-DOTBR_SRP_SERVER_AUTO_ENABLE=ON \
-	-DOTBR_TREL=ON
+	-DOTBR_TREL=ON \
+	-DOTBR_VENDOR_NAME="OpenThread" \


I wonder, not looked at it closely, shouldnt it be as OpenWrt? 🤔

I have considered this, but the CMake build does this:

set(OTBR_NAME "${OTBR_VENDOR_NAME}_${OTBR_PRODUCT_NAME}" CACHE STRING "The package name")

That would result in the package being name "OpenWrt-BorderRouter", which doesn't really make sense. We could go for VENDOR=OpenWrt PRODUCT=OpenThread-BorderRouter, or we could remove both variables which would expose --vendor-name and --product-name runtime options, but we'd have to integrate that in the netifd proto handler. I do not have a strong preference for either, so I went with what upstream does by default in their container.

In that case, I'm wondering how they work with this in openthread-br going forward. Do they use it for some statistics, and do they even collect data at all?

This is the first release with a proper version tag, unfortunately the git source tarballs do not include the submodules, so we can not use them. Use the version tag in PKG_SOURCE_VERSION instead of the commit hash, so it is clear from the resulting file which version it is. Remove upstreamed patches. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>

Upstream switched to internal mDNS implementation in commit openthread/ot-br-posix@fbf1e82. Drop the mDNSresponder dependencies as they are no longer needed. Also drop CMake options that conflict with upstream's new defaults. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>

CI has a version check script that checks for PKG_VERSION in the output of binaries included in the package. The binaries in this package do not return the actual version: root@iot-br1:~# /usr/sbin/otbr-agent --version 0.3.0 root@iot-br1:~# /usr/sbin/ot-ctl version OPENTHREAD/; POSIX; May 29 2026 22:35:39 Done Add a minimal custom version check script to avoid CI failures. Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>

neheb · 2026-06-23T21:44:57Z

So with a USB dongle implementing openthread at /dev/ttyACM0 , I get

Runtime error
Unhandled exception during request dispatching
/usr/lib/lua/luci/ucodebridge.lua:23: /usr/lib/lua/luci/template.lua:181: Failed to execute template 'admin_thread/thread_overview'.
A runtime error occurred: [string "/usr/lib/lua/luci/view/admin_thread/thread_..."]:24: attempt to index a nil value
stack traceback:
[string "/usr/lib/lua/luci/view/admin_thread/thread_..."]:24: in main chunk

In error(), file [C]
called from function [anonymous function] (/usr/lib/lua/luci/ucodebridge.lua:23)
called from function ((tail call))
In [anonymous function](), file /usr/share/ucode/luci/runtime.uc, line 148, byte 45:
  called from function [arrow function] (/usr/share/ucode/luci/dispatcher.uc:810:71)
  called from function render ([C])
  called from function render_action (/usr/share/ucode/luci/dispatcher.uc:797:24)
  called from function run_action (/usr/share/ucode/luci/dispatcher.uc:811:5)
  called from function [anonymous function] (/usr/share/ucode/luci/dispatcher.uc:1107:48)
  called from anonymous function (/www/cgi-bin/luci:39:13)

 `        return lcall.call(modname, method, ...args);`
  Near here ----------------------------------------^

Is this normal or something else needs to be done?

neheb · 2026-06-23T21:46:23Z

 	+libubox \
-	+libubus \
-	+mdnsd \
-	+mdnsresponder


So this was the only user of mdnsresponder. I think mdnsresponder should be removed in a follow up PR.

stintel · 2026-06-26T08:36:07Z

This needs more work:

HTTP REST server now binds to 127.0.0.1 by default so e.g. Home Assistant on a different host can no longer connect to it
netifd proto handler checks for service mdnsd and fails if it's not running - since it's no longer a dependency otbr-agent will not be started
if mdnsd is running this conflicts with the internal mDNS implementation, possibly the same problem happens when avahi is running

Switch OTBR_MDNS from mDNSResponder to openthread, drop the mdnsd and mDNSResponder dependencies, and remove the proto handler's mdnsd service check, which would otherwise refuse to start otbr-agent now that mdnsd is no longer installed. This follows upstream, which made the internal implementation the default in openthread/ot-br-posix#2996 and uses it in its own OpenWrt example package, and it lets otbr-agent share a router with umdns, which is what advertises the router's procd-registered services (ssh, samba and the like) and resolves <hostname>.local. The two can coexist because they never contend for a name: OpenThread's mDNS names its host after the Thread extended address, while umdns keeps <hostname>.local. Both bind UDP 5353 with SO_REUSEADDR and each answers only for its own records. mDNSResponder instead takes its name from gethostname(), so it and umdns race for the same name, and the loser either stops announcing without logging anywhere procd captures or, if neither notices, both keep claiming it. That is the conflict with a running mdnsd noted in openwrt#29784. Border router discovery is unaffected: in this mode OpenThread's own border agent registers the _meshcop._udp service (its OPENTHREAD_CONFIG_BORDER_AGENT_MESHCOP_SERVICE_ENABLE follows OPENTHREAD_CONFIG_MULTICAST_DNS_ENABLE), and OTBR's publisher is disabled by design, so clients such as Home Assistant still find the border router. Note that OpenThread's mDNS serves a single interface, the one given by the backbone_network option, so Thread service records are announced on that network only. Signed-off-by: Christian Glombek <c.glombek@cosa.systems> Assisted-By: Claude Fable 5

Switch OTBR_MDNS from mDNSResponder to openthread, drop the mdnsd and mDNSResponder dependencies, and remove the proto handler's mdnsd service check, which would otherwise refuse to start otbr-agent now that mdnsd is no longer installed. This follows upstream, which made the internal implementation the default in openthread/ot-br-posix#2996 and uses it in its own OpenWrt example package, and it lets otbr-agent share a router with umdns, which is what advertises the router's procd-registered services (ssh, samba and the like) and resolves <hostname>.local. The two can coexist because they never contend for a name: OpenThread's mDNS names its host after the Thread extended address, while umdns keeps <hostname>.local. Both bind UDP 5353 with SO_REUSEADDR and each answers only for its own records. mDNSResponder instead takes its name from gethostname(), so it and umdns race for the same name, and the loser either stops announcing without logging anywhere procd captures or, if neither notices, both keep claiming it. That is the conflict with a running mdnsd noted in openwrt#29784. Border router discovery is unaffected: in this mode OpenThread's own border agent registers the _meshcop._udp service (its OPENTHREAD_CONFIG_BORDER_AGENT_MESHCOP_SERVICE_ENABLE follows OPENTHREAD_CONFIG_MULTICAST_DNS_ENABLE), and OTBR's publisher is disabled by design, so clients such as Home Assistant still find the border router. Note that OpenThread's mDNS serves a single interface, the one given by the backbone_network option, so Thread service records are announced on that network only. Signed-off-by: Christian Glombek <c.glombek@cosa.systems> Assisted-By: Claude Opus 4.8

stintel · 2026-07-26T12:12:26Z

Let's continue this in #30091.

openwrt · 2026-07-26T12:12:30Z

Formality Check: Suggestions Available

We completed the verification flow. Please review the formatting overview logs below.

⚠️ STYLISTIC WARNINGS & SUGGESTIONS

Package Release Audit:

⚠️ Package net/openthread-br version updated from '2f3c799c7463c8f674754e65c53f78bc0bbcbd58' to '2026.06.0', but PKG_RELEASE was not reset to 1 (currently: '2')

_{Something broken? Consider reporting an issue.}
_{Running version 516b28e deployed on 2026-07-26 09:31:58 CEST}

Switch OTBR_MDNS from mDNSResponder to openthread, drop the mdnsd and mDNSResponder dependencies, and remove the proto handler's mdnsd service check, which would otherwise refuse to start otbr-agent now that mdnsd is no longer installed. This follows upstream, which made the internal implementation the default in openthread/ot-br-posix#2996 and uses it in its own OpenWrt example package, and it lets otbr-agent share a router with umdns, which is what advertises the router's procd-registered services (ssh, samba and the like) and resolves <hostname>.local. The two can coexist because they never contend for a name: OpenThread's mDNS names its host after the Thread extended address, while umdns keeps <hostname>.local. Both bind UDP 5353 with SO_REUSEADDR and each answers only for its own records. mDNSResponder instead takes its name from gethostname(), so it and umdns race for the same name, and the loser either stops announcing without logging anywhere procd captures or, if neither notices, both keep claiming it. That is the conflict with a running mdnsd noted in openwrt#29784. Border router discovery is unaffected: in this mode OpenThread's own border agent registers the _meshcop._udp service (its OPENTHREAD_CONFIG_BORDER_AGENT_MESHCOP_SERVICE_ENABLE follows OPENTHREAD_CONFIG_MULTICAST_DNS_ENABLE), and OTBR's publisher is disabled by design, so clients such as Home Assistant still find the border router. Note that OpenThread's mDNS serves a single interface, the one given by the backbone_network option, so Thread service records are announced on that network only. Signed-off-by: Christian Glombek <c.glombek@cosa.systems> Assisted-By: Claude Opus 4.8

GeorgeSapkin reviewed Jun 19, 2026

View reviewed changes

Comment thread net/openthread-br/Makefile Outdated

stintel force-pushed the bump/otbr branch 2 times, most recently from 903852c to cc0ad8c Compare June 20, 2026 05:54

This was referenced Jun 20, 2026

cgi-io: add generic version check override #29786

Merged

CI: package tests loop over every package artifact in /ci openwrt/actions-shared-workflows#121

Open

BKPepe reviewed Jun 20, 2026

View reviewed changes

Comment thread net/openthread-br/test-version.sh Outdated

BKPepe reviewed Jun 20, 2026

View reviewed changes

Comment thread net/openthread-br/Makefile

BKPepe reviewed Jun 20, 2026

View reviewed changes

stintel force-pushed the bump/otbr branch from cc0ad8c to b5754ec Compare June 20, 2026 11:59

BKPepe mentioned this pull request Jun 20, 2026

openthread-br: Decouple LuCI package from this repository #29791

Open

stintel added 3 commits June 23, 2026 09:14

stintel force-pushed the bump/otbr branch from b5754ec to c991360 Compare June 23, 2026 06:14

neheb reviewed Jun 23, 2026

View reviewed changes

stintel marked this pull request as draft June 26, 2026 08:26

This was referenced Jul 25, 2026

openthread-br: drop luci-app-openthread, moved to luci repo #30090

Closed

openthread-br: update to 2026.07.0, internal mDNS, configurable REST listen address #30091

Open

stintel closed this Jul 26, 2026

Uh oh!

Conversation

stintel commented Jun 19, 2026

📦 Package Details

🧪 Run Testing Details

✅ Formalities

Uh oh!

Uh oh!

Uh oh!

Uh oh!

BKPepe Jun 20, 2026

Choose a reason for hiding this comment

Uh oh!

stintel Jun 20, 2026

Choose a reason for hiding this comment

Uh oh!

BKPepe Jun 20, 2026

Choose a reason for hiding this comment

Uh oh!

BKPepe Jun 20, 2026

Choose a reason for hiding this comment

Uh oh!

stintel Jun 20, 2026

Choose a reason for hiding this comment

Uh oh!

BKPepe Jun 20, 2026

Choose a reason for hiding this comment

Uh oh!

neheb commented Jun 23, 2026

Uh oh!

neheb Jun 23, 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!

stintel commented Jun 26, 2026

Uh oh!

stintel commented Jul 26, 2026

Uh oh!

openwrt Bot commented Jul 26, 2026

Formality Check: Suggestions Available

⚠️ STYLISTIC WARNINGS & SUGGESTIONS

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

neheb Jun 23, 2026 •

edited

Loading