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.
This commit adds new helper macro `OT_SHOULD_LOG_AT(aLevel)` which
indicates whether logging is enabled at a given log level. This helps
simplify the code and makes sure the the condition used for enabling
logging related functions/methods is consistent across all the core
modules.
With this change, when `OPENTHREAD_CONFIG_LOG_OUTPUT` is set to
`LOG_OUTPUT_NONE` (which practically disables all logging), all the
related code/methods that are used to prepare the log line
(e.g. `Mac::OperationToString()`) are excluded from the build
(become empty functions/methods). This way, under `LOG_OUTPUT = NONE`
instead of preparing the log line and then passing it to an empty
`otPlatLog()` implementation to be dropped, the code is optimized to
not prepare the log line in first place.
This commit adds tests for NAT64 prefix
advertisement. BORDER_ROUTING_NAT64 is set to 1 to enable the feature
in tests.
It also adjusted some util functions for prefixes and routes in
netdata.
Testing outbound connectivity to IPv4 hosts is not covered yet. It
will be added after we update OTBR.
- 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 commit generates a random NAT64 prefix and adds the prefix to
NetworkData if none exits. The prefix will be saved in Settings for
recovery.
It also adds a new CLI command `br nat64prefix` to show the local
nat64 prefix.
A new config OPENTHREAD_CONFIG_BORDER_ROUTING_NAT64_ENABLE is defined
and used to guard the change.
This initial implementation only supports a single BR.
This commit enables `OT_BORDER_ROUTING` feature in some of the
build scripts (e.g., `script/check-scan-build` or `make-pretty`) so
that it is covered by github actions workflow CI.
This commit adds support for DNS Stateful Operations (DSO) as
specified in RFC 8490.
It adds `platform/dso_transport.hpp` header file which defines the
platform APIs/callbacks for DSO transport layer (e.g., DSN-over-TLS
or DNS-over-TCP).
The `Dso` module handles establishing connection with a peer, acting
either as a DSO client or server, establishing a DSO session over a
connection, and then sending and processing DSO request, response,
and unidirectional messages (including support for DSO TLV formats).
The `Dso` module also manages the session life cycle and timeouts,
namely the "Inactivity" and "Keep Alive" timeouts (including sending
and processing of Keep Alive messages when needed). It also handles
adding encryption padding before sending a message. It implements the
padding policy "Random-Block-Length Padding" from RFC 8467.
This commit also adds a detailed unit test `test_dso` covering the
behavior (including corner cases) of the `Dso` implementation. The
unit test provides an implementation of the DSO platform APIs which
emulate the DSO transport layer. It also includes a simplified alarm
platform implementation (emulating timers and allowing time to
advance in the unit test). These allow the unit test to cover more
complicated situations and behaviors (timeouts, failures, etc).
This commit removes `OPENTHREAD_CONFIG_LOG_DEFINE_AS_MACRO_ONLY`.
which helps simplify the logging implementation. This feature enabled
all logging including the platform API to be defined as macros and
was intended for certain restricted platforms. With the new logging
model, OpenThread core itself will prepare the entire log line
instead of platform layer, so this feature is no longer applicable or
useful.
This commit implements OTBR firewall. This implementation focuses on
ingress filtering. We may also introduce egress filtering when
necessary.
For security purpose, there are some packet forwarding rules to
follow, which were originally introduced in the spec.
- Inbound packets initiated with On-Link addresses source (OMR and
mesh local prefix based addresses) should be blocked.
- Inbound unicast packets whose destination address is not OMR address
or DUA should be blocked.
- Inbound unicast packets whose source address or destination address
is link-local should be blocked. Note that we don’t need to
explicitly add rules for link-local addresses since this should
already be handled by the kernel.
These rules can be easily implemented by iptables and ipset.
Before otbr-agent starts, there is a script creating the iptables
rules. The rules themselves are constant so we don't need to change
them dynamically. During the runtime of otbr-agent, otbr-agent updates
ipsets accordingly whenever there's a change of on-link prefixes.
This commit adds two simulation tests to verify that SRP clients can
register 500 services to one SRP server:
- Virtual time simulation test with one SRP server and 25 SRP clients,
each client registering 20 SRP services.
- OTBR simulation test same as above, but run SRP server on OTBR
(Docker).
This commit implements part of the OTBR firewall. This implementation
focuses on the ingress filtering part. We may also introduce egress
filtering part when necessary.
For security purpose, there are some packet forwarding rules to
follow, which were originally introduced in the spec.
- Inbound packets initiated with On-Link addresses source (OMR and
mesh local prefix based addresses) should be blocked.
- Inbound unicast packets whose destination address is not OMR address
or DUA should be blocked.
- Inbound unicast packets whose source address or destination address
is link-local should be blocked. Note that we don’t need to
explicitly add rules for link-local addresses since this should
already be handled by the kernel.
These rules can be easily implemented by iptables and ipset.
- Before otbr-agent starts, there is a script creating the iptables
rules. The rules themselves are constant so we don't need to change
them dynamically.
- During the runtime of otbr-agent, otbr-agent updates ipsets
accordingly whenever there's a change of on-link prefixes.
Background:
In an early stage of developing a new product, developers may want to
verify the Thread related hardware functionality, for example, send,
receive, etc. However if the product uses the posix <-> RCP mode,
it's hard to verify it before the posix daemon can run on the
host. cli-ftd and cli-mtd could be an alternative. However, if the
product uses the posix <-> RCP mode, the space of the 802.15.4 radio
chip will be very small. For example, nRF52811 doesn't have enough
space to flash cli-ftd or cli-mtd firmware. So this PR creates a new
firmware ot-cli-radio which has very limited functionality for
verifying the hardware.
Basically, the ot-cli-radio consists of openthread-radio and
libopenthread-cli-radio.a. It supports very few cli commands. The most
important command is diag. Currently, there are: diag, help, reset,
version.
Currently, the diag commands have different implementation on RCP:
- For commands like diag start, the process function
(Diags::ProcessStart) is first called on host. Then host sends an
SPI frame to the RCP and Diags::ProcessStart (different
implementation) is called again on RCP.
- For commands like diag send, Diags::ProcessSend is first called on
host. Then host sends an SPI frame to the RCP, directly calling
send API. And there is no Diags::ProcessSend implemented on RCP.
Let's call the implementation of Diags::Process* currently on host as
native diag commands. When we run ot-cli-radio, we should use the
native diag commands because it won't interact with a posix daemon and
it processes the diag commands through the whole process. So this PR
adds a new option OPENTHREAD_CONFIG_DIAG_NATIVE_CMDS_ON_RCP to control
whether to use the native diag implementation on RCP. When we use a
normal RCP, the option should be disabled. While when use
ot-cli-radio, the option should be enabled.
This commit adds a new class `AnycastLocator` which can be used to
locate the closest destination of an anycast IPv6 address (i.e., find
the related mesh local EID and RLOC16). The closest destination is
determined based on the the current routing table and path costs
within the Thread mesh.
The implementation uses a CoAP confirmable post request to a newly
added URI path ("a/yl"). The destination IPv6 address of such as
request message is set to the anycast address to be located. The
receiver of the request message sends a CoAP response which includes
the "Mesh Local EID" and "Thread RLOC16" TLVs.
This commit also adds support this new feature in CLI (adding a new
`locate <anycast-addr>` command).
Finally this commit adds `test_anycast_locator.py` to test behavior of
the new feature.
Yakun Xu