OpenThread version update to upstream

[saeidakbari]

The current OpenThread dependency in this repository appears to be significantly outdated (2+ years old). I'd like to inquire about plans for updating to a more recent version of OpenThread and understand the current maintenance status of this project.

Current Situation

• The OpenThread submodule/dependency hasn't been updated in over 2 years
• Missing potentially important security updates, bug fixes, and new features from upstream OpenThread
• This may impact compatibility with newer Thread specifications and ecosystem developments

Questions/Requests

1. Update Plans: Are there any plans to update the OpenThread dependency to a more recent version?
2. Maintenance Status: What is the current maintenance status of this esp-rs/openthread project?
3. Blockers: Are there any specific technical blockers preventing the update (e.g., ESP-IDF compatibility, breaking changes, etc.)?
4. Timeline: If updates are planned, is there an estimated timeline?
5. Community Contribution: Would the maintainers be open to community contributions to help with the update process?

[ivmarkov]

• Missing potentially important security updates, bug fixes, and new features from upstream OpenThread

Anything concrete you are missing?
The openthread submodule is pinned to https://github.com/openthread/openthread/tree/thread-reference-20230706 if I'm not mistaken.

There is no other - newer - tag in the openthread subrepo. I'm still struggling to understand their development. As in, is everything "stable"? Like, really? Can I just "pick a hash" and pin to it? What hash would that be?

If you have inner knowledge about the openthread dev process please enlighten me. Maybe every git hash in their main repo is stable?

• This may impact compatibility with newer Thread specifications and ecosystem developments

As per above, do you have anything in mind which you are currently missing?

Questions/Requests

1. Update Plans: Are there any plans to update the OpenThread dependency to a more recent version?

Yes, as long as there is a good reason to do it.

3. Maintenance Status: What is the current maintenance status of this esp-rs/openthread project?

I think active? If you look at the latest commits?

5. Blockers: Are there any specific technical blockers preventing the update (e.g., ESP-IDF compatibility, breaking changes, etc.)?

No blockers. ESP-IDF has their own openthread submodule and the Thread support in the esp-idf-* crates has its own Thread wrappers which are also actively maintained, and which are part of esp-idf-svc. If you want to use OpenThread with the esp-idf-* crates, look inside esp-idf-svc. This repo is for baremetal Rust projects only.

7. Timeline: If updates are planned, is there an estimated timeline?

?

9. Community Contribution: Would the maintainers be open to community contributions to help with the update process?

I am one of the maintainers and a community member. PRs always welcome, from everyone.

[ivmarkov]

Thinking loud:

Given the relative non-transparency of the openthread development process (unless it is just my perception - as per above, let me know if I'm missing something) we can do the following couple of things:

• Look at what hash the Matter C++ SDK is using/pinning w.r.t. their openthread dependency. At least these guys have proper tags, so we can look inside this one or maybe the tip of the 1.4.2 branch
• Look at what hash ESP-IDF is using. Looking inside ESP-IDF master might be good enough, or else the release/v5.5 branch.

As for backwards compatibility - my understanding is that OT is backwards compatible anyway.

[saeidakbari]

First of all thanks for your detailed answers.

1. "Anything concrete you are missing?"

Currently, the main concern is security updates, bug fixes, and spec compliance with the latest Thread standards (Thread 1.3.0+). Since the pinned submodule reference is from July 2023 (thread-reference-20230706), it misses:

• Any security patches introduced since that date.
• Potential interoperability fixes and performance improvements for Thread networks.
• Spec alignment with the latest Thread Certification guidelines and ecosystem devices (e.g., upcoming Matter devices).

I'm not aware of specific CVEs affecting OpenThread since July 2023, but long gaps between updates raise the risk of missing unpublicized security patches or optimizations.

---

2. "Is everything 'stable'? Like, can I pick a hash and pin to it? What hash would that be?"

From what I understand of OpenThread's dev process:

• main branch: It's actively developed and generally stable; CI ensures builds and functional tests pass.
• Reference tags (e.g., thread-reference-YYYYMMDD) are tested snapshots that Thread Group uses for certification, but they aren't released often.
• In theory, you can pick a recent commit hash from main and pin to it — it should work — but for maximum stability you’d normally pick:
  • The latest reference tag, or
  • A commit after the reference tag that includes important fixes.

My concern is that if the repo never updates to a newer reference tag, we might fall behind on spec compliance and bug fixes.

---

3. "As per above, do you have anything in mind which you are currently missing?"

Currently missing / potentially missing:

• Thread 1.3.0 features (if not fully backported).
• Newer border router interoperability improvements.
• Potential platform-level optimizations for newer chips.
• Any Matter-related Thread optimizations released after July 2023.

The risk is not knowing which of these have been addressed in upstream commits — the lack of an update process makes it harder to assess.

---

4. "Update Plans?"

I'd like to know:

• If there’s a policy for updating the OpenThread submodule (e.g., once per year, on new reference tags, or ad hoc).
• If newer upstream releases or commits will be evaluated periodically for integration.

---

5. "Maintenance Status?"

From my perspective:

• Yes, the repo seems active based on recent commits.
• But since updates to the OpenThread submodule haven't been done in over a year, the maintenance policy regarding upstream dependencies is unclear.

---

6. "Blockers?"

Understandable — no technical blockers.

• That’s good news, as it means a submodule update should be straightforward.
• However, without a process, it relies on someone noticing when upstream OpenThread advances.

---

7. "Timeline?"

If there’s an intention to update, even without blockers, it would be useful to know:

• Is this planned within weeks, months, or “when needed”?
• This affects whether I, or other community members, should initiate a PR.

---

8. "Community Contribution?"

That’s great — I’m willing to help with testing and preparing a PR to bump the OpenThread submodule, as long as we can agree on:

• The target commit/tag to pin to.
• How we validate stability (basic test plan).

---

Proposed Next Step

If helpful, I can:

1. Identify the latest stable commit on openthread/openthread since thread-reference-20230706.
2. Test it against the current esp-rs/openthread integration.
3. Submit a PR if results are positive.

[saeidakbari]

Here is the conversation on OT suggesting main branch is almost production ready with the help of CI: https://github.com/orgs/openthread/discussions/8239#discussioncomment-3808350

[ivmarkov]

In the meantime, they dumped another tag so I think at least updating our lib to track that tag would be harmless and completely safe.

[jdswensen]

I think the reference tags usually refer to what the certification test harness is using across all the test devices. I'd need to double check with the latest test harness though (which I don't have set up at the moment). As a note, Thread 1.4 was launched this year and all previous versions of the spec are being sunset. No new devices will be allowed to certify with older versions after December 31, 2025 so its definitely worth keeping up to date. Backwards compatibility will still be preserved obviously, just no new cert for older specs.

Can I just "pick a hash" and pin to it? What hash would that be?

For more frequent updates, the project could also reference the commit hashes that Silicon Labs ships in their SDK. For example, this PDF section 8.2 lists the commit 7f6723ffb. Tracking a vendor commit in this way will increase the likelihood of selecting a stable commit because the vendors will typically do a lot of internal testing before releasing their SDKs.

[ivmarkov]

I think the reference tags usually refer to what the certification test harness is using across all the test devices. I'd need to double check with the latest test harness though (which I don't have set up at the moment). As a note, Thread 1.4 was launched this year and all previous versions of the spec are being sunset. No new devices will be allowed to certify with older versions after December 31, 2025 so its definitely worth keeping up to date. Backwards compatibility will still be preserved obviously, just no new cert for older specs.

Can I just "pick a hash" and pin to it? What hash would that be?

For more frequent updates, the project could also reference the commit hashes that Silicon Labs ships in their SDK. For example, this PDF section 8.2 lists the commit 7f6723ffb. Tracking a vendor commit in this way will increase the likelihood of selecting a stable commit because the vendors will typically do a lot of internal testing before releasing their SDKs.

Indeed. Or we can track Espressif's hashes (I think I mentioned it earlier).

At the moment, I don't have a pressing need to update the OpenThread version, but if somebody does have that need, and is willing to contribute a PR, I don't mind accepting it as long as the examples, as well as the limited (currently) Thread support in rs-matter-embassy continue to operate.