Request to provide API/functions to change Operational Dataset while BR is in automatic-start mode — plus questions about separating BRs, discovering Joiners, and hiding devices (TZ-2075)

[kunjsn123]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

I want to change the Thread Border Router (BR) configuration while it is running in automatic start mode.
Currently, when the BR autostarts, it forms or joins a network automatically using the dataset from menuconfig or NVS.
I need a way to change the Operational Dataset programmatically or through an API when autostart is enabled.

---

Details

1. Changing the dataset in automatic start mode

Please provide (or expose) a function that allows updating the Operational Dataset when the BR is in automatic start mode.
If such a function already exists, please share:

• The function name and file name
• Example usage or call sequence

If it’s not available, please suggest the best method to do this safely — for example:

• Temporarily stop the Thread interface, apply new dataset parameters, and restart
• Or update dataset values stored in NVS so the BR restarts with new configuration

---

2. Separating two border routers

I want to make two border routers operate as independent Thread networks.
Right now, I’m changing only the network key, and that seems to separate them.
Please confirm whether this is the correct approach or suggest a better method.

Possible parameters to change include:

• Network Key
• Extended PAN ID
• PAN ID
• Channel
• Network Name

Which of these are required or recommended for complete separation?

---

3. Commissioning multiple Joiners

I’m also working on commissioning Thread devices.
Currently, I take a Thread client (Joiner) in joiner mode and start commissioning from the BR.

If I have multiple joiners nearby, how can I detect or list them, similar to a Wi-Fi scan that shows nearby devices?

I’ve already tested the CLI commands:

scan
discover

These only show devices that have already created or joined a network.
I need a way to see devices that are in joiner mode but not yet joined.

Please let me know if:

• There is a function or method to detect joiners in range
• Example code or file reference is available
• Any plan to add this feature in future

---

4. Hiding my Thread devices from other BRs

When I run the scan or discover command, I can see all nearby Thread devices.
Is there a way to hide my devices so that other Thread Border Routers (for example, from other vendors) cannot see or add them?

If there is an API or configuration for this, please provide:

• Function or configuration name
• File reference
• Example or short explanation

My goal is to make sure that only my own BR can see and commission my Thread devices.

---

Summary

Requested features / clarifications:

1. Function or API to change dataset while BR autostart is enabled
2. Best method to make two BRs independent networks
3. Method or API to discover nearby Joiners (like Wi-Fi scan)
4. Option to hide my devices from other BRs

---

[gytxxsy]

1. You can change the active dataset by calling otDatasetSetActiveTlvs. Please refer to setting dataset when autostart for an example.

2. The items that must be modified are the Network Key and the Extended PAN ID, but we recommend modifying all fields, as this appears to be a more proper approach.

3. I’m not quite sure what you mean by “detecting joiner.” What state are they in — interface up but Thread network not started?

4. As far as I know, there is currently no API that can make a device invisible to scans while the Thread network is running. You can refer to OpenThread’s code: handle kMacCmdBeaconRequest .When a device receives a Beacon Request, it will respond with a Beacon.

[kunjsn123]

1. You can change the active dataset by calling otDatasetSetActiveTlvs. Please refer to setting dataset when autostart for an example.
2. The items that must be modified are the Network Key and the Extended PAN ID, but we recommend modifying all fields, as this appears to be a more proper approach.
3. I’m not quite sure what you mean by “detecting joiner.” What state are they in — interface up but Thread network not started?
4. As far as I know, there is currently no API that can make a device invisible to scans while the Thread network is running. You can refer to OpenThread’s code: handle kMacCmdBeaconRequest .When a device receives a Beacon Request, it will respond with a Beacon.

Update

1. Changing dataset in autostart mode — resolved ✅
   Thanks! Using otDatasetSetActiveTlvs() works for us while BR is in automatic-start mode. We can now update the active dataset programmatically and then restart commissioner as needed.

2. Separating two BRs — resolved ✅
   Confirmed: changing Network Key and Extended PAN ID separates the networks; we now update the full dataset (Network Name, PAN ID, Channel, etc.) for a clean separation as recommended.

3. Discovering Joiners before connect — need clarification ❓
   To clarify my scenario:

• I start commissioning on the BR (Commissioner active).
• A Thread client is put into joiner mode (it’s not on any network; it’s in “discover”/joiner state).

Question: From the BR side, is there any API/event to list or detect nearby joiners before they actually start the DTLS handshake?

• Think of this like Wi-Fi “scan”: can the BR show “joiners in range” that are in joiner mode but not yet attached?
• I tried scan / discover but those only show existing Thread networks (routers/end-devices), not unattached joiners.

If the answer is “not possible by design” (i.e., joiners don’t beacon/advertise until they initiate commissioning), could you please confirm that the only visibility we get is:

• When the joiner actually initiates the DTLS session to the Border Agent/Commissioner, and
• We can catch that via some callback or signal? If so, which API should we hook (e.g., an ot-commissioner callback, OTBR D-Bus signal, or any example showing how to log “Joiner Hello” attempts with EUI-64/RSSI)?

4. Hiding devices from other BRs — understood ❌
   Acknowledged: there’s no API to make an active Thread device invisible to scans while the network is running (devices reply to Beacon Requests per spec). We’ll rely on commissioning controls (PSKc/steering data, not enabling joiner role, etc.) rather than trying to hide devices at the MAC/mesh level.

Thanks again! If there’s any recommended hook/example for catching incoming joiner attempts on the BR side (even before authorization), a pointer to the function/file would be super helpful.

[gytxxsy]

3. Discovering Joiners before connect — need clarification ❓
   To clarify my scenario:

• I start commissioning on the BR (Commissioner active).
• A Thread client is put into joiner mode (it’s not on any network; it’s in “discover”/joiner state).

Question: From the BR side, is there any API/event to list or detect nearby joiners before they actually start the DTLS handshake?

• Think of this like Wi-Fi “scan”: can the BR show “joiners in range” that are in joiner mode but not yet attached?
• I tried scan / discover but those only show existing Thread networks (routers/end-devices), not unattached joiners.

If the answer is “not possible by design” (i.e., joiners don’t beacon/advertise until they initiate commissioning), could you please confirm that the only visibility we get is:

• When the joiner actually initiates the DTLS session to the Border Agent/Commissioner, and
• We can catch that via some callback or signal? If so, which API should we hook (e.g., an ot-commissioner callback, OTBR D-Bus signal, or any example showing how to log “Joiner Hello” attempts with EUI-64/RSSI)?

For a Thread joiner, it only performs actions such as sending a discovery request or initiating a DTLS handshake when it attempts to join a network. Therefore, by design, there is no functionality for “receiving inquiries from other Thread devices and announcing itself as a joiner”.

If you want to detect all joiners, you can only monitor discovery request packets on the network. However, these packets typically use temporary extended addresses as source addresses, so they cannot be used to identify the devices. All of these behaviors are defined by the Thread protocol stack to ensure security.

Additionally, if you only want to monitor events when the commissioner is performing a DTLS handshake with a joiner, OpenThread provides related callbacks. Please refer to the following links:

• otCommissionerStart
• HandleJoinerEvent example

[zwx1995esp]

Hi @kunjsn123 Thread internal commissioning requires that the joiner can be selected via EUI64. A commissioner can search the target joiner with a specific EUI64. Please refer to otCommissionerAddJoiner.

Here is a link you can refer to process a thread local commissioning.

[kunjsn123]

3. Discovering Joiners before connect — need clarification ❓
   To clarify my scenario:

• I start commissioning on the BR (Commissioner active).
• A Thread client is put into joiner mode (it’s not on any network; it’s in “discover”/joiner state).

Question: From the BR side, is there any API/event to list or detect nearby joiners before they actually start the DTLS handshake?

• Think of this like Wi-Fi “scan”: can the BR show “joiners in range” that are in joiner mode but not yet attached?
• I tried scan / discover but those only show existing Thread networks (routers/end-devices), not unattached joiners.

If the answer is “not possible by design” (i.e., joiners don’t beacon/advertise until they initiate commissioning), could you please confirm that the only visibility we get is:

• When the joiner actually initiates the DTLS session to the Border Agent/Commissioner, and
• We can catch that via some callback or signal? If so, which API should we hook (e.g., an ot-commissioner callback, OTBR D-Bus signal, or any example showing how to log “Joiner Hello” attempts with EUI-64/RSSI)?

For a Thread joiner, it only performs actions such as sending a discovery request or initiating a DTLS handshake when it attempts to join a network. Therefore, by design, there is no functionality for “receiving inquiries from other Thread devices and announcing itself as a joiner”.

If you want to detect all joiners, you can only monitor discovery request packets on the network. However, these packets typically use temporary extended addresses as source addresses, so they cannot be used to identify the devices. All of these behaviors are defined by the Thread protocol stack to ensure security.

Additionally, if you only want to monitor events when the commissioner is performing a DTLS handshake with a joiner, OpenThread provides related callbacks. Please refer to the following links:

• otCommissionerStart
• HandleJoinerEvent example

Thanks @gytxxsy for the detailed explanation.

I understand that by Thread design, joiners don’t announce themselves until they send a discovery request or start the DTLS handshake — and that this behavior ensures security.

My goal, though, is to build a fully automated wireless commissioning workflow for IoT devices. In our setup, the Thread Border Router (BR) should handle all device onboarding wirelessly, without needing to physically interact with or reflash the joiner device after initial programming.

That’s why I was asking if there’s any mechanism for the BR to identify which nearby devices are currently in joiner (discover) mode but not yet attached to any network — essentially, a “pre-joiner discovery” similar to how Wi-Fi scanning shows nearby devices before connection.

I now understand this isn’t available in the current Thread specification — joiners stay silent until they actively start the join process — but from a practical automation standpoint, it would be very useful if the BR could at least:

Detect incoming discovery requests and expose those events via a callback or log, and

Optionally provide basic info (RSSI, temporary address, channel) for network-side diagnostics.

This kind of event visibility would help manage large-scale, unattended device onboarding where devices come online automatically in joiner mode.

Could you please confirm if OpenThread or OTBR provides any hooks or examples for catching these discovery request packets or other low-level indications from joiners before the DTLS handshake starts? Even if it’s just a packet-sniffer style callback, that would be extremely useful for our automation pipeline.

Thanks again for clarifying — this feature would make a big difference for projects aiming for fully wireless provisioning workflows.

[kunjsn123]

Hi @kunjsn123 Thread internal commissioning requires that the joiner can be selected via EUI64. A commissioner can search the target joiner with a specific EUI64. Please refer to otCommissionerAddJoiner.

Here is a link you can refer to process a thread local commissioning.

Thanks @gytxxsy and @zwx1995esp.

I understand the part about using otCommissionerAddJoiner() with a specific EUI-64 to allow only that joiner.

My question is: how can I get the EUI-64 of a nearby joiner device in a real deployment, without physically touching the device or pre-configuring it?

My goal is to achieve fully wireless onboarding:

The Border Router acts as the Commissioner.

A new device powers on in joiner mode (not on any Thread network yet).

The BR should automatically detect and add only my own devices, not any random nearby joiners.

To do that, I need a way to know the EUI-64 of nearby joiners before commissioning starts — something like a pre-joiner discovery step.

Is there any API, callback, or log on the BR side that can show:

A joiner is nearby or attempting discovery, and

Its EUI-64 (and maybe RSSI or channel info),
so I can then call otCommissionerAddJoiner() dynamically for that specific device?

Or is the joiner’s EUI-64 only available after the commissioning process begins (i.e., during DTLS handshake or later)?

I checked the link you shared (ESP OpenThread Hardware Codelab
), and it shows how to add a known EUI-64 joiner.
But in my use case (automatic field deployment), I don’t want to manually type or pre-store each EUI-64 — the Border Router should discover and authorize them wirelessly.

So, to confirm:

Can the BR/Commissioner read or detect the EUI-64 of nearby joiners before commissioning actually starts?

If yes, which function, callback, or example file should I refer to for this?

This would be very helpful for automatic provisioning systems that need to detect and authorize devices purely over Thread without manual setup. 🙏

[kunjsn123]

Hi @kunjsn123 Thread internal commissioning requires that the joiner can be selected via EUI64. A commissioner can search the target joiner with a specific EUI64. Please refer to otCommissionerAddJoiner.
Here is a link you can refer to process a thread local commissioning.

Thanks @gytxxsy and @zwx1995esp.

I understand the part about using otCommissionerAddJoiner() with a specific EUI-64 to allow only that joiner.

My question is: how can I get the EUI-64 of a nearby joiner device in a real deployment, without physically touching the device or pre-configuring it?

My goal is to achieve fully wireless onboarding:

The Border Router acts as the Commissioner.

A new device powers on in joiner mode (not on any Thread network yet).

The BR should automatically detect and add only my own devices, not any random nearby joiners.

To do that, I need a way to know the EUI-64 of nearby joiners before commissioning starts — something like a pre-joiner discovery step.

Is there any API, callback, or log on the BR side that can show:

A joiner is nearby or attempting discovery, and

Its EUI-64 (and maybe RSSI or channel info), so I can then call otCommissionerAddJoiner() dynamically for that specific device?

Or is the joiner’s EUI-64 only available after the commissioning process begins (i.e., during DTLS handshake or later)?

I checked the link you shared (ESP OpenThread Hardware Codelab ), and it shows how to add a known EUI-64 joiner. But in my use case (automatic field deployment), I don’t want to manually type or pre-store each EUI-64 — the Border Router should discover and authorize them wirelessly.

So, to confirm:

Can the BR/Commissioner read or detect the EUI-64 of nearby joiners before commissioning actually starts?

If yes, which function, callback, or example file should I refer to for this?

This would be very helpful for automatic provisioning systems that need to detect and authorize devices purely over Thread without manual setup. 🙏

@zwx1995esp @gytxxsy @chshu is there any updates ?

[gytxxsy]

@zwx1995esp @gytxxsy @chshu is there any updates ?

For the commissioner, specifying the joiner’s EUI-64 is not mandatory. You can omit the joiner’s EUI-64, and when the joiner attempts to join, it must meet the PSKD requirements. This ensures that not just any joiner can connect to the commissioner — they must share the same PSKD.

There is no way to pre-scan nearby devices for their EUI-64 and then configure them into the commissioner. You can refer to the following APIs for more details on how to use them.

• otJoinerStart
• otCommissionerAddJoiner
• otCommissionerAddJoinerWithDiscerner

[kunjsn123]

@zwx1995esp @gytxxsy @chshu is there any updates ?

For the commissioner, specifying the joiner’s EUI-64 is not mandatory. You can omit the joiner’s EUI-64, and when the joiner attempts to join, it must meet the PSKD requirements. This ensures that not just any joiner can connect to the commissioner — they must share the same PSKD.

There is no way to pre-scan nearby devices for their EUI-64 and then configure them into the commissioner. You can refer to the following APIs for more details on how to use them.

• otJoinerStart
• otCommissionerAddJoiner
• otCommissionerAddJoinerWithDiscerner

@gytxxsy thank you for answer , i got my answer but i suggest you that , your team should work on this feature of joiner scan