This commit removes the OPENTHREAD_CONFIG_TMF_PROXY_DUA_ENABLE feature
and all associated code, tests, CLI commands, and harness references.
Changes:
- Removed OPENTHREAD_CONFIG_TMF_PROXY_DUA_ENABLE definition and all
assert/preprocessor checks.
- Completely deleted dua_manager.cpp and dua_manager.hpp.
- Removed DUA registration notifying and request URI paths.
- Cleaned up all references to Domain Unicast Address (DUA) across
child management, notifier, time ticker, and MLE.
- Removed DUA commands and logic from the CLI and Python cert tests
(including packet verifier).
- Verified that the entire codebase compiles clean and all tests
successfully pass using the Nexus test suite.
In order to facilitate a well-staged post reset process for a larger
size link, it is important to consider the timing of devices returning
to the link.
With the changes in this PR, that timing will be as follows:
1. The leader and routers will begin sending link request messages in
an attempt to reattach to the previous partition.
2. Both the leader and routers will have 4 attempts to reconnect,
afterwords falling back to attach any.
3. The leader here is given a 2s retry window (jittered 10% either
way), for a worst-case (tightest timing vs routers) of 4x2.2s =
8.8s before starting attachment.
4. The routers here are given the normal 5s multicast retx delay with
the same 10% jitter, resulting in a tightest timing (shortest) of
4x4.5s = 18s
5. For this analysis, the jitter during the attach process is ignored
because it will not be particularly significant, so we assume both
flow through a nominal failed attachment of 2x0.75s (routers) +
4x1.25s (reeds) = 6.5s
6. This means that the previous leader will start the new partition
around 15.3s after starting.
7. The former routers would fall back to starting a new partition on
their own at 24.5s after reset.
This timing leaves 9.2s of leeway (greater than the length of the full
attachment process) for the routers to get parent responses from the
old leader which has started the new partition and attach instead of
starting their own partitions.
This also leaves sufficient time between the router attachment and
children timing out of their role restoration process to attach to
their former parents.
Additionally, 4 attempts should be more than sufficient with this
timing to successfully reattach to a partition that did not also
reset. If a link request sent in this period is not accepted, then the
old partition can be safely assumed to be gone, or removed links to
the reset device.
Routers with children and the leader will also benefit in
single-device reset cases here because they are able to rejoin more
quickly. Only routers with very few/no children are slowed down in
re-attachment by 5s.
Renames LINK_LOCAL_All_THREAD_NODES_MULTICAST_ADDRESS to
LINK_LOCAL_ALL_THREAD_NODES_MULTICAST_ADDRESS and
REALM_LOCAL_All_THREAD_NODES_MULTICAST_ADDRESS to
REALM_LOCAL_ALL_THREAD_NODES_MULTICAST_ADDRESS across the test
scripts to ensure consistent ALL_CAPS_WITH_UNDERSCORES casing
for constants, adhering to PEP 8 and project conventions.
With the router restoration, longer delay is expected. This commit
defines the router restoration delay and apply it on the unstable test
case Cert_5_1_05_RouterAddressTimeout.
This commit introduces the `RouterRoleRestorer` class, nested within
`MleRouter`, to manage router/leader role restoration after an MLE
operation restart (e.g., a device reboot) by sending multicast Link
Requests. This class simplifies the code and centralizes role
restoration logic.
Specific changes:
- A new member variable `mLastSavedRole` is added to track the last
attached role (saved in non-volatile memory). This is used by
`RouterRoleRestorer` to determine the number of Link Request
attempts. This variable replaces the previous `mWasLeader`, which
was only updated after a reboot and would not account for role
changes afterward.
- The `AttachTimer` is now used for role restoration instead of the
retransmission timer, as role restoration always occurs while the
device is detached and before any attach attempts.
- The `kLinkRequestTimeout` is used for the last attempt before
considering restoration failure.
- The `mChallengeTimeout` mechanism is now removed (in earlier Thread
specification versions, multicast Link Requests could be used while
the device was attached, but this is no longer used or needed).
- `test-012-reset-recovery.py` is updated to validate the role
restoration behavior. `test_detach` is also updated and fixed.
This commit targets to support getting infra link-local address of a
OtbrNode in docker test, which is usefully for future test cases.
The test_multi_ail.py is also updated to test the new method added.
### Background
https://github.com/openthread/openthread/pull/10550 introduced a new
way to support multiple backbone nework in otbr docker test. Though it
works good while running a single test, a bug exists when running
cert-suite, which runs a batch of tests in parallel.
cert-suite allocates the name of the backbone interfaces dynamically
by setting env PORT_OFFSET for each test, so there is potentially
conflict exists if we hard code the `backbone_network` name in
TOPOLOGY. This PR is targeting to fix this potential naming conflict.
### Fix
We fix it by assigning a number for `backbone_network_id` in each BR
definition in TOPOLOGY, instead of setting a fixed `backbone network`
name. The final backbone network name is decided by both `PORT_OFFSET`
env and the number of `backbone_network` (in
`backbone{PORT_OFFSET}.{backbone_network}` format)
For example, if `PORT_OFFSET` is 0 and `backbone_network_id` is 1,
then backbone network name will be `backbone0.1`. For the tests that
only use one backbone network and the `backbone_network_id` is not
given, the backbone network name is by default
`backbone{PORT_OFFSET}.0`.
### New test case format
```
class NewTestCase(thread_cert.TestCase):
...
BR = 1
...
TOPOLOGY = {
BR: {
...
'is_otbr': True,
'backbone_network_id': <backbone-id>,
...
}
...
}
...
```
`<backbone-id>` is any integer from 0, for each BR inside a single
test, if `<backbone-id>` is different, the BR use different backbone
interfaces; the same `<backbone-id>` inside a single test case means
the same backbone network interface.
`'backbone_network_id': <backbone-id>` is optional for single backbone
test cases, when it's not given while defining a otbr node, the
backbone is default as `backbone{PORT_OFFSET}.0`.
For developers, if you are defining a new test which has multiple
backbone interfaces, please ensure `backbone_network_id` is explicitly
defined in each BR, otherwize an error is reported.
In previous otbr docker tests, when creating docker containers, all the
containers(otbr nodes) are connected to the same docker network bridge `backbone0`
(when the env PORT_OFFSET is not set or set to 0), this means all the
otbr nodes are connected to the same infrastructures.
This commit adds support to enable user to config otbr instance
infrastructures seperately in `TOPOLOGY` when defining test cases, this
provides flexibility to run multi-ail related test cases.
The format to define backbone interface per node is:
```
class NewTestCase(thread_cert.TestCase):
...
BR = 1
...
TOPOLOGY = {
BR: {
...
'is_otbr': True,
'backbone': <backbone-name>,
...
}
...
}
...
```
`'backbone': <backbone-name>` is optional, when it's not given when
defining a otbr node, the backbone is default as
`BACKBONE_DOCKER_NETWORK_NAME`. The `<backbone-name>` is suggested to be
defined as `backbone[0-9]` to make it more easy to read and understand.
This commit also adds test_multi_ail.py as an example test case to use
this new method, this test case checks the two otbr nodes are connected
to the different infra and are in the same Thread mesh network.
This commit drops UDP datagrams from an untrusted origin to TMF port.
Examples of untrusted origin:
- A process other than OT on the host sends the packet to Thread
network via platform API.
- A packet forwarded from infrastructure network to Thread network by
Thread Border Router.
OT shouldn't allow UDP datagrams from untrusted origins going to TMF
port of any Thread device.
To implement this, there's an API `otIp6SendFromOrigin`
introduced. This can be used for specifying the origin of a packet you
want to send. This commit also encapsulates the 'origin' information
in `Message::Metadata`.
This commit migrate tests not targeting autotool to cmake.
* removed openthread-test-driver
* removed functional tests from autotool based check
* corrected file permission of python scripts
* added --run-directory to specify directory to collect logs and captures
* get test-ot-test-srp-server pass on POSIX platform
According to Thread 1.3.0 Section 4.7.1.3, router synchronization
after reset requires the multicast link request message to be
retransmitted until a response is received, or the maximum
transmission limit has been reached. If the router was a leader or had
more than 5 children prior to reset, it MUST be retransmitted as a
critical message. Each multicast retransmission of an MLE Message on a
TL1 or TL2 Link must be delayed by MLE_MULTICAST_RETRANSMISSION_DELAY
multiplied by a random value between 0.9 and 1.1 with a resolution of
at least 1 ms.
This commit implements the above requirement. With this requirement,
in the cases when a router is reset and there is no other router to
respond to the link request then it takes longer time for the router
to join thread network. Thus some test cases are modified to allow
longer router sync time in such cases.
This commit updates the MLE attach process so that in the first attach
cycle device tries a total of six MLE Parent Requests, the first two
to routers only followed by four to routers and REEDs. For example,
the six Parent Request message will be used before device can decide
to act the leader. An MTD in the next attach attempt (if cannot find a
parent in first attempt cycle), will go to the model of two Parent
Requests (first to routers, then to routers/REEDs).
This change impacts the time it takes for a device to start as leader
(due to increased number of Parent Request and wait time). This commit
updates different test scripts to address the change in the wait
time. It adds a new `config.LEADER_STARTUP_DELAY` constants which is
used for wait time for leader to start.
Deriving the Mesh Local Prefix from the Extended PAN ID was carried
forward from legacy implementations. Removing this coupling to conform
to the existing Thread Specification.
- Adds platform API `trelDnssdInitialize` to initialize TREL
DNS-SD module.
- Adds `test_trel_connectivity.py` test.
- Fixed `Border Router` TREL test to really use TREL.
This commits updates `thread-cert/Makefile.am` adding some existing
tests that were not included in the Makefile when the tests were
added. It also sorts the entries to be in alphabetical order.
This commit also updates the access control mode for all script files
to be executable by all (`chmod 755` or "-rwxr-xr-x").
This commit changes border agent service to use ephemeral port by
default. This change makes it easier to support multiple Thread
interfaces on a single host.
This commit implements DNS-SD Discovery Proxy.
- Implemented DNS-SD Discovery Proxy functionalities - OT part
- Fixed an memory issue of NameCompressInfo (introduced in #6155 , but
somehow revealed by this commit)
Some implementation details:
- Discovery Proxy subscribes to services/service instances/hosts
through callbacks set by a public OT API. It is up to the platform
mDNS implementation to collect service instance/host information and
notify OT via a public OT API.
- Discovery Proxy can handle DNS browsing of one service or DNS
resolving of one service instance/host. We leave browsing multiple
services or resolving multiple service instances/hosts for future
enhancements if necessary.
Accept RA initiated from the infra interface so that we can detect the
existence of another RA daemon which is working on the same infra
interface.
Also enhance the test_single_border_router.py test script to make it
more readable.
This is the initial implementation of Thread Border Router
prefix/route management with:
- Create & publish off-mesh routable (OMR) prefix for Thread network
- configure the BR as default route.
- converge to the smallest OMR prefix if multiple prefixes are
present at the same time.
- Create & advertise on-link prefix for infrastructure network
- monitor RA messages on infra link and stops myself if there is
someone else advertising an on-link prefix.
It currently supports single infrastructure link with possibly
multiple BRs. Support for multiple infrastructure links is left for
future.
This commit implements DUA features of Thread 1.2 DUA that involves
sending and processing Backbone query and answer:
- Extend address query to the Backbone Link
- Send BB.qry for Thread address query
- Send ADDR_ANS.ntf for BB.ans
- DAD process
- PBBR to send BB.qry on the Backbone link (3 times if not answered)
- PBBR to receive and handle BB.qry and sends BB.ans
- PBBR to receive BB.ans and sends ADDR_ERR.ntf if duplicated
- PRO_BB.ntf
- Send PRO_BB.ntf when DUA registration is updated
- Handle PRO_BB.ntf
- Add test_dua_dad.py to test the DAD process when it was successful
or duplicated
- Verify the normal DAD process
- Verify Address Query can be extended to the Backbone link
- Verify DAD duplicate is handled correctly
- Verify PRO_BB.ntf for duplicated DUA is handled correctly
This commit implements the Forward Tracking Series feature in Link Metrics.
- Two new apis are added:
- otLinkMetricsSendMgmtRequestForwardTrackingSeries, which is used
to send an MLE Link Metrics Management Request
- otLinkMetricsSendLinkProbe, which is used to send an MLE Link Probe
- A new class LinkMetricsSeriesInfo is used to maintain the data of
one Series configured by a neighbor. This class inherits
LinkedListEntry and each Neighbor has a list of
LinkMetricsSeriesInfo. All LinkedListEntrys are allocated and freed
by a Pool in LinkMetrics.
- To specify SeriesFlags in cli command for Forward Tracking Series, a
similar approach with LinkMetricsFlags is used. Another character
flags is used to represent SeriesFlags.
- Whenever the node receives a frame (including ACK) from a neighbor,
it would call Neighbor::AggregateLinkMetrics which goes through each
LinkMetricsSeriesInfo entry in the neighbor's list and aggregate the
data if the frame type matches the entry.
- Two test scripts are added to test this function:
- v1_2_LowPower_7_2_01_ForwardTrackingSeries.py
- v1_2_LowPower_test_forward_tracking_series.py
- backbone/test_mlr_multicast_routing.py verifies the basic features
of Backbone multicast routing
- backbone/test_mlr_multicast_routing_timeout.py verifies that MLR
timeout works
- backbone/test_mlr_multicast_routing_commissioner_timeout.py verifies
that Commissioner MLR timeout works
This commit enhances Backbone Router to send BMLR.ntf on the backbone
link for Multicast Listeners.
- Send BMLR.ntf to the Backbone link
- Add Backbone test with packet verification
- Includes some revision to the Thread 1.2 Backbone CI scripts to make
it more stable
This commit is the first part in link metrics. It implements single
probe function.
An overview of major changes:
- Add link metrics apis which allow apps to send a single probe and
set report callback.
- Add cli commands for calling link metrics api and related README
doc.
- Add a new module link_metrics to implement the query process and
handle the report.
- Add related tlv types.
- Add simple script test to run single probe process.
Thread 1.2 CI with OTBR and Backbone link:
- Run OTBR in Dockers with Backbone link
- Enhance node.py to work with OTBR Docker
- Add Packet Verification for 5.11.1
- incomplete, some steps can not pass yet, just to make sure
Backbone traffic verification works
- Support running multiple tests simultaneously (default: each test
run 3 instances)
- Build OTBR Docker using OpenThread PR code
- Upload code coverage in Docker
Some implementation details:
- Most existing code of node.py is shared by OTBR Docker
- Backbone related test scripts are found in
tests/scripts/thread-cert/backbone
- A new script tests/scripts/thread-cert/run_bbr_tests.py is added to
manage multiple running tests
- Test configuration differs according to PORT_OFFSET
- Backbone interface name: Backbone{PORT_OFFSET}
- Backbone network prefix: 91{PORT_OFFSET:02x}::/64
- Docker instance name: otbr_{PORT_OFFSET}_{nodeid}
- Output Files:
- Pcap:
- Thread: {test_name}_{PORT_OFFSET}.pcap
- Backbone: {test_name}_{PORT_OFFSET}_backbone.pcap
- Merged: {test_name}_{PORT_OFFSET}_merged.pcap
- Log: {test_name}_{PORT_OFFSET}.log
This commit runs Thread 1.1 certification tests with packet
verification for 1.2 build because Thread 1.2 certified devices are
supposed to be able to pass Thread 1.1 certification first.
Note: changes to test TOPOLOGY:
- Original: nodes use version=1.1 by default
- Now: nodes use version according to ENV, except explicitly specified
If CSL Channel is never specified, the actual CSL channel should
always be the phy channel that the device is using. If CSL Channel
hasn't been specified and radio channel changes, the actual CSL
channel should also change. In current implementation, CSL Channel is
by default a valid value (not specified by upper layer) and wouldn't
change when radio channel changes even if it's never specified.
This commit fixes this issue. On CSL receiver, a bit is extracted from
mCslChannel to be used as a flag mIsCslChannelSpecified. If it is
false, mCslChannel would keep synchronized to the value of
mRadioChannel in Mac and Csl Channel TLV wouldn't be appended in Child
Update Request to its parent. On CSL transmitter, CSL channel info in
child is allowed to be 0. If it's 0, the channel info in frame would
be set using Mac::GetPanChannel.
This commit implements the CSL feature in Thread 1.2.
- Add macro definitions for low power to control the compiling of
source code.
- Add data and methods for running CSL in Mac and SubMac. This mainly
includes setting CSL parameters, starting/stopping CSL, and the
timer handling process.
- Add otPlatTimeGetAPI and implementation.
- Add CSL transmission implementation. CSL transmission is a new kind
of transmission, the related definition and implementaion for the
whole transmitting process is added.
- Add calling of start/stop CSL in certain cases.
- Implement CSL synchronization maintainence. If a CSL cordinator
didn't get a frame containing CSL IE for CSLTimeout, the CSL
receiver is regarded as de-synchronized.
- Add Cli interface for using CSL.
- Implement enhanced Ack with IE. The original code can only generate
auto ack for Imm-Ack. As CSL requires CSL IE included in enhanced
ack. This PR implements it.
- Add basic functional test for CSL transmission. More tests
corresponding to test plan would be added later.
- registration workflow framework
- registration and reregistration
- registration and reregistration on behalf of children
- add pseudo response status for test/certification purpose
- add unit test
This commit includes:
- Adding compile configurations necessary for MLR features
- Adding source/header files necessary for MLR features
- Send MLR.req for local MAs on ThreadNetif
- At most one MLR.req is outstanding
- Reregistration according to PBBR configuration
- Renewing periods according to PBBR configuration
- BBRs receive MLR.req with minimal processing and send MLR.rsp
- Add a test to verify that MLR.req is sent for local MAs.
This commit includes:
- cache domain prefix in the Thread Network
- subscribe/unsubscribe AllDomainBBRs Multicast address
- update test to cover AllNetworkBBRs and AllDomainBBRs subscription
Jonathan Hui