Help: ot-daemon vs otbr-agent

[dakhnod]

Looking through the OpenThread page, I can find two different daemons for the OpenThread stack on linux:

• ot-daemon (https://openthread.io/platforms/co-processor/ot-daemon)
• otbr-agent (https://openthread.io/guides/border-router/build)

Thus I have these questions:

1. What are the differences between the two? After all, they both create a network interface wpanX that can be used for border-routing?
2. Which one should I use? Is there any reason not to use exclusively border routers on Raspberry Pis?

Thanks!

[superwhd]

If you'd like to make your device a Thread Border Router, you should use otbr-agent.

ot-daemon's capability is no more than a Full Thread Device (FTD).

Is there any reason not to use exclusively border routers on Raspberry Pis?

I think it depends on what features you need for your device.

[dakhnod]

@superwhd Thanks! Yet, could you please consider this question:

Both programs create the interface wpanX, which Linux can internally route.
With that, is ot-daemon not also a border router?

What sets them apart?

[Irving-cl]

@dakhnod

I would say the concept of 'border router' is very broad. If we only talk about 'border routing' (IPv6 bidirectional connectivity, a device on the infrastructure network can communicate with a device in the thread network, via the border router), yes, ot-daemon is also capable of that. Because the key to make that work is to send and receive (handle) ICMPv6 Neighbor Discovery messages. The code to do these things are in OT core so ot-daemon contains them. And the posix platform implementation enables OT core to operate on infrastructure link. (send and receive ICMPv6 ND messages)

But a 'border router' contains much more things than 'border routing':

1. Border Agent, which is used for Thread commissioning. The border router needs to publish a service "meshcop" on the infrastructure link. This is done in otbr-agent.
2. Backbone router, which enableds two Thread partitions can communicate through an infrastructure link. Thread devices from two partitions will communicate using a domain unicast address. To make this work, the border router needs a route that forwards all packets with desitination within the DUA prefix into the Thread network. This route is installed by code in 'otbr-agent'.
3. TREL. The code to publish TREL service and actively browse TREL neighbors are in 'otbr-agent'.
4. mDNS service. otbr-agent depends on external mDNS service to publish services (mDNSResponder or avahi). otbr-agent contains a 'client' to call services provided by mDNSResponder or avahi.

'otbr-agent' also have a few functions that are not directly related with Thread protocol (ot-daemon doesn't have them):

1. dbus interface. otbr-agent provides a few dbus APIs to control the Thread network. For example, join, leave, get/set various properties, etc.
2. OTBR web. This provides a web application to control the Thread network.

[dakhnod]

Thanks a lot! I am grateful for every piece of information I can get on this, since I am still learning a lot.

Could you please help me on these questions?

1. Did I get it right that when I install and launch the otbr-agent, it creates its own network?
2. How can I configure otbr-agent to join another network?
3. How can I configure all otbr-agents for a domain?
4. How do I configure all otbr-agents in order to allow for thread devices to roam between them e.g. if I physically move a device within the domain?

Thanks in advance and posterior for your time!

[Irving-cl]

1. No. There is an argument --auto-attach for otbr-agent. If this is passed, otbr-agent will start a network itself. As I can see, if you install and launch it, the service file generated won't have this option.
2. You can use ot-ctl or dbus. ot-ctl should be better as a start point. ot-ctl allows you to run some cli commands. To join another network, run these commands by ot-ctl:

# First you have obtained the active dataset of your target Thread network in hex format
ot-ctl dataset set active <dataset_of_target_network>
ot-ctl ifconfig up
ot-ctl thread start

For 3&4, I'm not sure if I understand it correctly. Domain is a concept in Backbone Router. I think this [whitepaper] (https://www.threadgroup.org/Portals/0/documents/support/Thread%201.2%20Base%20Features.pdf) (Check 'BackBone Routers') may help.

[dakhnod]

Thanks!

Regarding 3,4: AFAIK a Thread domain consts of multiple thread partitions, each with one PBBR. For this, if I understand correctly, my backbone border routers somehow need to know of each other.

1. In any case, how do I configure a border router to act as an BBR, and to discover other BBRs?

2. Did I get it right that the DUA is meant to be used to address a device in a domain, regardless of the partition it resides in? So the DUA shouldn't change when the device roams between partitions?

[dakhnod]

For completeness I want to mention that the active dataset can be obtained by using the command ot-ctl dataset active -x

[Irving-cl]

Hi @dakhnod,

First I want to mention that it seems that the DUA feature isn't quite useful now. The same thing can be simply done by 'border routing'. For example, if we have two Thread networks (each have a BR) and they are connected through a backbone link, then Thread nodes from the two networks can access each other by OMR addresses. So not sure if you really want to use DUA.

---

To let the BR be capable of a BBR for DUA, enable these options: -DOT_DUA=ON -DOTBR_DUA_ROUTING=ON. But note that in a Thread network, there will only be one primary BBR (PBBR). They will automatically elect the PBBR when there are multiple BRs. You don't need to do extra configurations to start the functionality.

The BBRs (on a backbone link) don't need to discover each other. In the Thread network, configure a Domain Prefix using prefix command. For example:

prefix add fd00:7d03:7d03:7d03::/64 prosD med

The 'D' flag means domain prefix. Then the devices in the Thread network will register their DUA addresses at the BBR.

Did I get it right that the DUA is meant to be used to address a device in a domain, regardless of the partition it resides in? So the DUA shouldn't change when the device roams between partitions?

The DUA is generated by SLAAC if a device doesn't configure its DUA iid. So if you set the DUA iid and moves a device to another partition (using same domain prefix), the address shouldn't change. Otherwise, the device will have a new address generated by SLAAC.

[dakhnod]

Thanks!
Some more questions...

1. Could you please explain what this means then?

> prefix                                                                                                                                                                                  │
fdf1:3ce3:1296:1::/64 paos low 5400 

2. Is this not a DUA prefix?
3. If I am not using DUA, is there any other way of giving every device a partition-agnostic address? So each devices stays reachable even after roaming with the same address?
4. The way you told me to configure the routers (by cloning the dataset from one to the other), is that the same as one joining the network?
5. If 4) applies, does that take away from the 32 router limit? Let's say I have 50 border routers with the same dataset, how can I make sure the organize into multiple partitions of a domain?

[EskoDijk]

@dakhnod DUA prefix with DUA addresses were indeed designed to have a stable IPv6 address for a Thread Device, valid within a given "domain" (called Thread Domain), while the device is potentially roaming between different networks. These are Thread networks with each a unique Network Key. And the Border Routers for all these networks must be connected on a single infrastructure IPv6 link, to make the DUA feature work.

Only the function of roaming between networks in the domain isn't released yet by Thread Group (see my comments in #10536 ) - instead, a device vendor may use pre-configured active datasets for multiple Thread Networks in the domain today, as a substitute until the roaming feature becomes available. I don't think OT currently supports such multi-network configuration though it could be implemented on top.

So depending on your use case it may be easier to use the #10536 suggested solution of Partitions at physically separate sites. (Also network-wise the infrastructure links on these sites need to be separate. So this is very different from the conditions of using DUA.)

[dakhnod]

Could you please elaborate on OMR a bit more? How do I get such an address and what does it look like? And how is it generated?

[abtink]

@dakhnod some suggestions/link to learn more about OMR prefix/addresses:

• The BorderRouting docs
• Thread 1.3. Webinar video
• Also can check Thread 1.3 specification (section 9.6.1)

[dakhnod]

@abtink couly you please summarize the difference between the joiner id and the eui64 of a thread device?

[jwhui]

@abtink couly you please summarize the difference between the joiner id and the eui64 of a thread device?

• EUI-64 is a factory-assigned static identifier.
• Joiner ID is computed as a hash of EUI-64.

openthread/src/core/meshcop/meshcop.cpp

Line 286 in 6e46e2e

void ComputeJoinerId(const Mac::ExtAddress &aEui64, Mac::ExtAddress &aJoinerId)