Setting up BBR/DUA/NDPROXYING

[Lander Noterman]

Hello,

For our application, I would like to experiment with/evaluate the Thread 1.2 features Backbone router, DUA routing and NDProxying, however I can't seem to find any information on how to set this up. Is there any documentation on this? Even a glossary with some definitions for the various terms used in the config options would be helpful.

Thanks!

[ga...@eero.com]

I haven't played with these features myself, but there's this codelab which might help. 

[Jonathan Hui]

When building OTBR, set the OTBR_DUA_ROUTING build option to enable the DUA feature.

You can also reference the tests/scripts/thread-cert/backbone/test_dua_routing.py CI script we use for testing the feature.

Hope that helps.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/8ca24f0c-c00e-4a4b-a67f-6987cb427a8bn%40googlegroups.com.

[Lander Noterman]

Thank you for your responses, I will look into these resources.

One of the use cases I'm trying to solve is "bridging" (potential) Thread partitions over an IP interface. After looking into this some more, I noticed I might not need Thread 1.2 Backbone router/NDProxying features to make this work, two border routers with correctly configured "TREL" should suffice, is this correct?

Op dinsdag 10 augustus 2021 om 02:26:47 UTC+2 schreef Jonathan Hui:

[Simon Lin]

TREL works for you if all the BRs belong to the same Thread network. 

You may also use Border Routing feature which uses OMR addresses and RAs to manage the routes between Thread and WiFi:

-D OTBR_BORDER_ROUTING=ON

[Lander Noterman]

Thanks for the suggestions.

For now, all BRs belong to the same Thread network, so TREL would fit our use case. We're currently using the ML-EID in our application (in combination with Service ALOCs), so using TREL would also minimize the changes we would need to do to our application if I understand correctly.

In my first tests, I have some trouble getting TREL to work correctly. Here is my setup:

Router A <--TREL--> Router B <--THREAD--> Router C

In this case, Router A is a TREL-only POSIX "controller" (just for testing, IRL this will be TREL+THREAD), Router B is an intermediary TREL+THREAD POSIX router and Router C is a Nordic Thread-only lamp.

I can see OpenThread has correctly formed the network including the TREL links:

On Router A:

# ot-ctl neighbor table
| Role | RLOC16 | Age | Avg RSSI | Last RSSI |R|D|N| Extended MAC     |
+------+--------+-----+----------+-----------+-+-+-+------------------+
|   R  | 0x9400 |   2 |      -20 |       -20 |1|1|1| 2261e111773d79c8 | // Router B

Done
# ot-ctl extaddr
be0110ec20e2fa86

Done

On Router B:

# ot-ctl multiradio neighbor list
ExtAddr:be0110ec20e2fa86, RLOC16:0x4400, Radios:[TREL(255)] // Router A
ExtAddr:2203d43e64285cc1, RLOC16:0x7000, Radios:[15.4(255)] // Router C
Done
# ot-ctl extaddr
2261e111773d79c8
Done

I'm capturing packets via Wireshark on Router A's wpan0 interface and I'm controlling the light device (Router C) by sending Confirmable CoAP messages to it's ML-EID.

In this setup, everything is working correctly: the confirmable messages are received by the lamp and the corresponding ACKs are received by the controller.

However, whenever I introduce another (non-router capable) Thread device to the network (let's call this Child A), the communication seems to break: CoAP messages to the lamp are still received, but I can't see the corresponding ACKs on the controller. The child device is also supposed to communicate with the controller over CoAP, but I can't see any communication on the Wireshark capture from Router A.

When I now remove Router C (the lamp) from the network, communication with Child A starts working for a while, but after some time, it seems to stop working again and no communication is happening between Child A and Router A (over Router B).

When adding extra lamp devices instead of the Child-only device, they don't seem to cause issues.

These devices were all working correctly in a network where TREL was not configured. Is it possible there is some incompatibility or bug in the TREL implementation that could explain this behaviour?

I'll try to reproduce this behaviour using the toranj test environment and report back.

Op dinsdag 10 augustus 2021 om 10:00:12 UTC+2 schreef simo...@google.com:

[Abtin Keshavarzian]

Thanks for trying out TREL (specially happy to see you are using TREL only device :)...).

> These devices were all working correctly in a network where TREL was not configured. Is it possible there is some incompatibility or bug in the TREL implementation that could explain this behaviour?

I cannot think of any immediate reason (related to TREL behavior or otherwise) why adding a new child may impact this. 

> I'll try to reproduce this behaviour using the toranj test environment and report back.

Thanks. I agree, I think that would be best idea.  `test-703-multi-radio-mesh-header-msg.py` uses a somewhat similar topology.

Abtin.

[Lander Noterman]

A small status update: I wasn't able to reproduce the behaviour using the simulator. I noticed that when I configure our MTD to function as an FTD, the problem goes away, but I can't reproduce the same behaviour using a nRF52840 DK or Dongle (configured as an MTD), so it seems like there must be something about our MTD that is causing issues.

I will have to investigate further to pin down the root cause of the issue.

Op dinsdag 10 augustus 2021 om 21:40:01 UTC+2 schreef Abtin Keshavarzian: