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
* [coap] Add option scanning functions
In a few places in the OpenThread code-base, the following construct is
seen:
```
otCoapOptionIterator iterator;
otCoapOptionIteratorInit(&iterator, message);
for (const otCoapOption *opt = otCoapOptionIteratorGetFirstOption(&iterator);
opt != NULL;
opt = otCoapOptionIteratorGetNextOption(&iterator))
{
if (opt->mNumber == OT_COAP_OPTION_DESIREDOPTION)
{
doSomethingWith(opt);
break;
}
}
```
or its equivalent. In cases where multiple options are sought, the
above is still the better approach (using a `switch` statement), but
otherwise this seems repetitive.
`otCoapOptionIteratorGetFirstOptionMatching` basically implements the
above loop, returning the first option that matches. This same code can
also be used for testing for presence too by comparing the resultant
pointer to the `NULL` singleton.
For completeness in cases where a software developer may want to
*resume* looking for further matching options,
`otCoapOptionIteratorGetNextOptionMatching` is also provided.
* [coap] Add function for decoding Uint options
To properly implement features such as RFC7641 and RFC7959, one must be
able to decode unsigned integer options. It seems silly to have an
encoder but not a decoder, so here is the missing piece.
Future considerations may be a `uint32_t` version since the majority of
use cases do not call for a `uint64_t`; the type was chosen since it was
the most general case.
* [coap] Reference the RFC for the Observe option.
For the sake of completeness, reference the relevant RFC in the
documentation so that developers can read up more on how it should work.
* [coap] Add mObserve flag to metadata.
When we're implementing observations, a few exceptions to the usual CoAP
conventions apply, notably:
- when we receive the initial reply, the request is _not_ finished, we
will receive subsequent requests until we tell the server to stop.
- when we send a confirmable notification, the observing client will
reply with an `ACK` with no further traffic: we need to differentiate
this from an empty `ACK` to a request meaning we should expect a reply
later.
While we could just repeatedly scan for the `Observe` option on the
request, that is wasteful in terms of processing time. This allows us
to scan the request just once, and set a single-bit flag to save
processing later.
* [coap] Don't expect traffic after ACK to notification
If the client sends an empty `ACK` in reply to a confirmable RFC7641
notification, we will _NOT_ see further replies with additional
information. Consider the notification as acknowledged and pass the
details back to the application.
* [coap] Pass through notifications to handler
Ensure that all notifications sent by the CoAP server are passed back to
the application's CoAP request handler. When we receive the first one,
the request continues -- it does not finish until the server drops the
`Observe` flag or we tell the server to stop.
* [coap] Disable expiry timer once subscribed
If a request carries `Observe=0` and we receive the first reply, ignore
future time-out events as the transaction will finish only when
explicitly terminated.
* [coap] Support eager subscription cancellation
A CoAP client may signal its intention to unsubscribe from a resource by
sending a `GET` request with a token matching that of the original
request and setting the `Observe` option to the value 1.
In the event the application does this, we should pick this up and
cancel the pending transaction locally. The handler will be notified of
this by a final call where `aError=OT_ERROR_NONE` and no message given.
* [cli] Add RFC7641 support to CLI example
As an aide to those developing code that uses RFC7641, implement an
example client and server that supports this feature.
Yakun Xu