This commit add a new feature in `Srp::Client` to allow user to
specify the lease and/or key lease intervals explicitly per service.
The lease intervals in a service can be left unspecified(set to zero)
in which case the default lease intervals will be used.
In an SRP Update message, the lease info is included in additional
section in an Update Lease Option record. Therefore the lease values
are applicable to the entire message and all its records. If we have
services with different lease intervals, they need to be registered
in separate messages. This commit updates `Srp::Client` to implement
such a mechanism. When preparing an SRP message, we first determine
the lease and key lease intervals and ensure the services using
matching intervals are included in the message.
This commit also updates and simplifies the "single service mode"
functionality to use the newly added mechanism for tracking which
services are included in the message.
This commit adds `test_srp_register_services_diff_lease` which covers
the behavior of the newly added mechanisms.
This commit updates CLI `linkmetrics query` command to allow it
to be used in blocking mode (wait for response to query). This
is then used in different tests to validate the `LinkMetrics`
module behavior. In particular, `v1_2_test_single_probe` and
`v1_2_LowPower_7_2_01_ForwardTrackingSeries` are updated to
validate that the received query report message is correctly
parsed.
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 adds a "auto host address mode" in SRP client. When
enabled, host IPv6 addresses are automatically set by SRP client
using all the unicast addresses on Thread netif excluding the
link-local and mesh-local addresses. If there is no valid address,
then Mesh Local EID address is added. The SRP client will
automatically re-register when/if addresses on Thread netif are
updated (e.g., new addresses are added or existing addresses are
removed).
This commit updates CLI to add support for new SRP client APIs related
to the new feature. It also adds `test_srp_auto_host_address` test to
cover the behavior of this feature.
This commit adds an API `otThreadDetachGracefully` to notify other
nodes in the network (if any) and then stop Thread protocol
operation. It sends an Address Release if it's a router, or sets its
child timeout to 0 if it's a child.
I just found that we don't have a test case covers the scenario of
DNS-SD when there are multiple BRs. Specially, one of the BRs starts
with no mDNS cache.
There was a time that our mDNS publisher answered the queries
correctly, even when there was a bug in mDNS publisher that it
cancelled resolving/browsing too early (was fixed in
https://github.com/openthread/ot-br-posix/pull/1120). That bug was
hidden because mDNS cache already contained the needed information.
This commit implements new logging model in OpenThread. Each core
module can specify its own module name using `RegisterLogModule()`.
The registered log module name is then included in the all the log
messages emitted from the specific file. This model replaces and
enhances the log region model.
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 introduces a number of enhancements to `thread-cert`
Border Router tests to improve reliability:
- Checks `ot-rcp` process status for OTBR tests to help catch errors
earlier
- Make sure `ot-rcp` processes are terminated after one test to avoid
corrupting subsequent tests
- Upload core dump as artifacts if otbr-agent crashed
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 implements new radio filter mechanism in OpenThread. The
radio filter is mainly intended for testing. It can be used to
temporarily block all tx/rx on the IEEE 802.15.4 radio. When radio
filter is enabled, radio is put to sleep instead of receive (to
ensure that the device does not receive any frame and/or potentially
send ack). Also the frame transmission requests return immediately
without sending the frame over the air (return "no ack" error if ack
is requested, otherwise return success). This commit also add CLI
command `radiofilter` for this feature. It also adds test-case
`test_radio_filter` to validate the behavior of the new feature.
This feature requires `OPENTHREAD_CONFIG_MAC_FILTER_ENABLE`.
HostNode is based on OtbrDocker, which has otbr-agent service started
by default. We should disable this service on HostNode otherwise the
border router test cases won't have the exact expected topology.
Added new API/CLI for reference devices to set allowed ranges of
router IDs. When the allowed ID range is set, the leader will only
assign router IDs in the range. In this way, we can assign
non-overlapping router ID ranges to different thread networks so that
no RLOC16s will collide across multiple thread networks.
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.
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.
This commit updates `Srp::Server` to add support for selecting its
address mode (unicast or anycast). The address mode specifies how the
SRP server determines its address and port number and how this info
is published in Thread Network Data.
In anycast address mode, the SRP server will use port number 53 which
is also used by DNS resolver/server. So if both `Srp::Server` and
`Dns::ServiceDiscovery::Server` are enabled on a device, they both
need to listen on the same port number and share the same UDP socket
instance. This commit adds the mechanism in the code to realize this.
The `Srp::Server` will monitor when/if DNS-SD is active and checks
whether the port numbers match and if so it will close its own socket
and re-use the one from DNS-SD. In this case, an incoming UDP message
is first given to `Srp::Server` to process and if it fails to process
it then the message is given to DNS-SD.
This commit also adds CLI commands under `srp server` to get/set the
address mode (and update the `README_SRP_SERVER.md` documentation).
It also adds a new test `test_srp_server_anycast_mode` which covers
the SRP server address mode and the newly added behaviors.
This commit adds a new parameter `aSendUnregToServer` to SRP client's
`RemoveHostAndServices()` API. This parameter determines the behavior
when the host info is not yet registered with the server. If it is
set to `false` (which is the default/expected value) then the SRP
client will immediately remove the host info and services without
sending an update message to server (no need to update the server if
nothing is yet registered with it). If it is set to `true` then the
SRP client will send an update message to the server. Note that if
the host info is registered then the value of `aSendUnregToServer`
does not matter and the SRP client will always send an update message
to the server requesting removal of all info.
One situation where this parameter can be useful is on a device
reset/reboot where the caller may want to remove any previously
registered services with the server. In this case, caller can
`SetHostName()` and then request `RemoveHostAndServices()` with
`aSendUnregToServer` as `true`.
This commit also adds `test_srp_client_remove_host.py` which
verifies the behavior the newly added mechanism between client and
server.
This commit adds History Tracker feature and its CLI support. This
feature records history of different events as the Thread network
operates (e.g., history of RX and TX IPv6 messages or network info
changes).
Recorded entries are timestamped. When the history list is read, the
timestamps are given as the entry age relative to the time the list
is being read. For example in CLI a timestamp can be shown as
`02:31:50.628 ago` indicating the entry was recorded 2 hours, 31 min,
50 sec, and 628 msec ago. Number of days is added for events that are
older than 24 hours, e.g., `31 days 03:00:23.931 ago`. Timestamps use
millisecond accuracy and are tacked up to 49 days. If an event is
older than 49 days, the entry is still tracked in the list but the
timestamp is shown as old or `more than 49 days ago`.
The `HistoryTracker` currently maintains 3 lists. The Network Info
history tracks changes to Device Role, Mode, RLOC16 and Partition ID.
The RX/TX history list records information about the received/sent
IPv6 messages:
- Message type (UDP, TCP, ICMP6 (and its subtype), etc.)
- Source and destination IPv6 addresses and port numbers
- IPv6 payload length
- The message checksum (for UDP, TCP, or ICMP6).
- Whether or not the link-layer security was used
- Message priority: low, norm, high, net (for control messages)
- Short address (RLOC16) of neighbor who send/received the msg
- Received Signal Strength (in dBm) for RX only
- Radio link info (15.4/TREL) on which msg was sent/received
(useful when `OPENTHREAD_CONFIG_MULTI_RADIO` is enabled)
Config `HISTORY_TRACKER_EXCLUDE_THREAD_CONTROL_MESSAGES` can be used
to configure `HistoryTracker` to exclude Thread Control message
(e.g., MLE, TMF) from TX and RX history.
The number of entries recorded for each history list is configurable
through a set of OpenThread config options, e.g., number of entries
in Network Info history list is specified by OpenThread config option
`OPENTHREAD_CONFIG_HISTORY_TRACKER_NET_INFO_LIST_SIZE`. The
`HistoryTracker` will keep the most recent entries overwriting oldest
ones when the list gets full.
This commit also adds support for `HistoryTracker` in CLI. The CLI
commands provide two style for printing the history information: A
table format (more human-readable) and list style (better suited for
parsing by machine/code). `README_HISTORY.md` is added to document
the commands and the info provided by each history list entry.
This commit also adds `test_history_tracker.py` test-case which
covers the behavior of `HistoryTracker`.
Per RFC 4862 section 5.5.3, the SLAAC address of a on-link prefix
will not immediately be invalidated even if the on-link prefix is
sent with zero PIO valid lifetime but we currently removes the
external route for the on-link prefix when we see zero valid lifetime.
This results in an error case that a Thread device can not reach
a valid SLAAC address of a Wi-Fi host on the same infra link because
there is no routes for this address.
This commit fixes this issue by delay removing the external route
for the discovered on-link prefix untill its valid lifetime expires.
Meanwhile, the Border Router now considers a deprecated (zero preferred
lifetime) on-link prefix not usable. Thus, the Border Router will
start advertising its own on-link prefix when current on-link prefix
is deprecated.
This commit implements a new feature "Network Data Publisher" which
provides mechanisms to limit the number of similar entries (service
and/or prefix) in the Thread Network Data by monitoring the Network
Data and managing if or when to add or remove entries. This feature is
enabled using `OPENTHREAD_CONFIG_NETDATA_PUBLISHER_ENABLE` config, or
`NETDATA_PUBLISHER` in autoconf, or `OT_NETDATA_PUBLISHER` cmake
option.
This commit adds support for publishing DNS/SRP anycast/unicast
service, on-mesh prefix, and external route prefix entries.
When there is a request to publish an entry, the `Publisher` monitors
the Network Data and counts the number of similar entries. If there
are fewer entries than a desired target number, the entry is added
after a short random delay.
If there are too many similar entries, `Publisher` starts the process
of removing its own entry (again after some random wait time). When
removing entries, certain entries are preferred over others (e.g., an
entry from a router over one from an end-device or if they are from
the same type of node, the one with smaller RLOC16). If `Publisher`
determines that its own entry is a preferred one, it adds an extra
wait time before removing its entry. This gives higher chance for a
non-preferred entry from another device to be removed before removing
a preferred entry which helps towards quicker convergence of the
process to the desired number of entries.
On-mesh prefix and external route entries have a "preference" field.
When publishing such an entry, a matching entry in the network data is
counted only if its preference is same or higher than the entry's
preference. This ensures that a device with a higher preference entry
publishes its entry even when there are many lower preference similar
entries in the network data (potentially causing a lower preference
entry to be removed).
This commit also adds `test_netdata_publisher.py` to verify the
behavior of the `Publisher`.
whd