This commit adds the following new API:
- otBorderRoutingProcessIcmp6Ra
And related APIs:
- otBorderRoutingDhcp6PdSetEnabled
- otBorderRoutingGetPdOmrPrefix
They are used to support the DHCPv6 PD on Thread Border Routers. On a
typical OS, the DHCPv6 Client of the platform network stack will
request a IPv6 subnet via DHCPv6-PD, then invoke the daemon for
sending router advertisements on the given interface.
With this commit, the RA will be catched by the processTransmit in
netif.cpp, which will then pass the message to
otBorderRoutingAddPrefixByRouterAdvertisement, RoutingManager will
then add the prefix according to the PIO in the router advertisement,
and take care of the lifetime of the prefix added.
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
This commit adds new Network Diagnostic TLVs for vendor name, vendor
model and vendor software version. The TLVs follow similar format as
the MeshCoP TLVs with the same name, i.e., all of them use UTF8
strings as value with name and model limited to 32 characters, and
software version to 16 characters.
The values for these TLVs can be set at build-time using a set of
newly added configs `OPENTHREAD_CONFIG_NET_DIAG_VENDOR_*`, or their
equivalent CMake options (e.g., `OT_VENDOR_NAME`).
It is recommended that these parameters are set at build time using
the configs. This way they are stored as constant strings and won't
consume RAM. However, for situations where the OT stack is integrated
as a library into different projects/products, we can enable a
feature for APIs to be added to set these strings at run-time. In
this case, the `OPENTHREAD_CONFIG_NET_DIAG_VENDOR_*` are treated as
the default values (used when OT stack is initialized).
This commit also adds Thread Stack Version TLV which has a string
value (up to 64 characters) and provides the version string from
`otGetVersionString()`.
This commit also adds CLI commands to get and set (when enabled) the
vendor name, model, and sw version on device. Also adds a test case
`test-020-net-diag-vendor-info.py`.
This commit introduces `Server` and `Client` classes breaking the
`NetworkDiagnostic` module into two components. The `Server` responds
to queries and requests (handling Net Diag TMF commands), while
`Client` issues queries/requests and processes responses. The
`Server` is available under both FTD and MTD (which follows the
requirement of Thread spec). The client is enabled using newly added
`OPENTHREAD_CONFIG_TMF_NETDIAG_CLIENT_ENABLE` config option which is
also available as `OT_NETDIAG_CLIENT` CMake option or the autoconf
build switch `NETDIAG_CLIENT`. The client functionality is by default
enabled on Border Routers (tied to `CONFIG_BORDER_ROUTING_ENABLE`
config).
The previous `TMF_NETWORK_DIAG_MTD_ENABLE` config is now removed
along with its CMake `OT_MTD_NETDIAG` and autoconf switch. This
commit adds checks to trigger build error if the previous config
and/or its related CMake option are used.
This commit adds a new file
`tests/scripts/thread-cert/border_router/nat64/test_upstream_dns.py`
to test scripts for testing the DNS forwarding functions.
The test adds a record `test.domain` to the bind9 interface since when
adding to DNSSD tests, the OpenThread's DNSSD server will be conflict
with the Docker's DNS forwarding functions.
`script/clang-format` is supposed to add an EOF newline for every file
passed in as an argument. However, the script only processed the first
file. This can cause `script/make-pretty check` to fail even after
`script/make-pretty clang`.
This commit contains changes to child supervision feature. It adds a
new mechanism for a child to inform its desired supervision interval
to its parent. A new optional MLE TLV is added with type 27 and value
of `uint16_t` indicating the supervision interval in seconds. This
TLV is included in MLE Child ID Request and MLE Child Update Request
(sent from the child). The parent echoes back this TLV in the
corresponding responses to indicate that it supports supervision. This
commit changes the parent implementation to track the supervision
interval per child.
This commit also updates the OT public APIs along with the related
CLI commands:
- API now allows the supervision interval to be set on a child.
- New field in `otChildInfo` to indicate the child's supervision
interval.
- New counter is added to track the number of supervision check
timeouts failures on a child (intended for testing and debugging).
This commit adds a test `test_child_supervision` to cover behavior of
child supervision and its new behaviors.
This change allows backward compatibility: If the parent does not
support child supervision, it ignores the new TLV in the MLE messages
and the child would fall back to periodically exchanging MLE Child
Update Request with parent. If the child does not support supervision
and/or does not indicate its desired child supervision interval, the
parent will fall back to use the configured default interval.
This commit adds a set of APsI for forwarding a DNS query to the
upstream DNS server via platform API and a posix platform
implementation.
This feature is disabled by default, and this PR adds a `dns server
upstream {enable|disable}` command CLI for enabling and disabling this
feature.
Tests will be added after ot-br-posix adds related support.
This commit lets `do_build_otbr_docker()` skip unnecessary files when
copying the source code for building a docker image. It can save time
and disk space for the user.
BR features are tested with "Border Router" CI task but it is built
with gcc by default. This commit adds BR features to posix build
checks which apply clang/clang++.
This commit migrates unit tests to cmake.
* build unit tests with cmake
* add missing tests in cmake
* use ctest
* add platform udp stubs for test platform
* skip some static_assert with gcc-4
We decided to rename BORDER_ROUTING_NAT64 to NAT64_BORDER_ROUTING so
the flag won't be confusing since we have NAT64_TRANSLATOR which does
not depends on the border routing manager.
This commit:
- implements the core logic for translating packets for NAT64,
including the public APIs exposed to platform daemons.
- includes changes for POSIX platform, use `OT_POSIX_NAT64_CIDR`,
`OPENTHREAD_POSIX_CONFIG_NAT64_CIDR` for setting the CIDR for NAT64
during build time.
- exposes `otNat64Send(otInstance *aInstance, otMessage *aMessage)`
and `void otNat64SetReceiveIp4Callback(otInstance *aInstance,
otNat64ReceiveIp4Callback aCallback, void *aContext)`.
This commit fetches the NAT64 prefix on infrastructure interface and
advertise it to Network Data at medium preference.
- Use `getaddrinfo_a()` function to asynchronously lookup the ipv6
address of the special domain `ipv4only.arpa`. The infrastructure
NAT64 prefix is extracted from the domain answer.
- `mInfraIfNat64PrefixStaleTimer` is scheduled to monitor the presence
and change of infrastructure NAT64 prefix.
- `EvaluateNat64Prefix` evaluates whether to advertise the
infrastructure prefix or the local ULA prefix or neither. When there
is a new infrastructure prefix, it will withdraw the legacy one and
add the new one. When the infrastructure prefix no longer exists, it
will withdraw the legacy one and add the local ULA prefix. When the
infrastructure prefix presents again, it will add the infrastructure
prefix and withdraw the local ULA prefix.
New tests are added to test the scenarios when infrastructure NAT64
prefix exists. `DNS64` on OTBR is turned on to enable `bind9` with
NAT64 prefix on infrastructure interface for these tests. `bind9` is
explicitly turned off when testing local ULA prefix. Since bind9 is
conflict with other components like dnssd, all nat64 tests are moved
under /nat64 directory and configured separately.
The case that two or more BRs have same infrastructure NAT64 prefix is
not covered by this commit and will be followed up later.
This commit updates the code to allow the config combination of
`OPENTHREAD_CONFIG_MESSAGE_USE_HEAP_ENABLE` along using external heap
`OPENTHREAD_CONFIG_HEAP_EXTERNAL_ENABLE`. This commit updates `Message`
`GetFreeBufferCount()` and `GetTotalBufferCount()` methods to return
special value `0xffff` under this config combo indicating the numbers
cannot be estimated.
This commit also updates `check-simulation-build-autotools` to add
such a build config so to be covered as part OT CI tests.
The bootstrap script taps `armmbed/formulae`, and then tries
to install `arm-none-eabi-gcc` from that tap. However, if the
user has already tapped a different tap that offers
`arm-none-eabi-gcc`, then the install will fail.
This change removes the ambiguity of the install by specifying
the tap to use.
This commit changes the NAT64 CI tests to be ran as an independent
job. A new /nat64 folder is added and it would make it easier to
configure new NAT64 tests in the future.
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.
This commit updates `check-simulation-build-autotools` to use the
`LOG_OUTPUT` switch directly. This addresses an issue where
we could end up with multiple `OPENTHREAD_CONFIG_LOG_OUTPUT`
definitions in the `CPPFLAGS`.
Some of the current implementations of thread stack use active scans
to find out the joining network name and extended panids. These
details are then used as part of commissioning process.
So at the very minimum we will need processing the incoming beacons to
extract these information.
