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`.
This commit includes a test case to verify that multiple border
routers can publish their meshcop services successfully without
instance name conflicts.
This commit adds a new feature in DNS client to automatically set and
update the server's IPv6 address in the default config. This is done
only when user does not explicitly set or specify the server address.
This behavior requires SRP client and its auto-start feature to be
enabled. SRP client will then monitor the Thread Network Data for
DNS/SRP Service entries to select an SRP server. The selected SRP
server address is also set as the DNS server address in the default
config.
This commit also adds `test_dns_client_config_auto_start.py` which
verifies the behavior of the new feature. In particular, that the DNS
client's default config gets changed and mirrors the SRP client
selected server address (when not set by user) and that it remains
unchanged if user explicitly sets the address in the default config.
This commit adds support for service subtypes in SRP server. It
updates the internal data model to store services in `Srp::Server`.
Every `Host` now has a list of `Service` entries along with a list of
`Service::Description` entries. These types mirror the SRP update
message format and the set of instructions that form the SRP message.
The `Service` entries represent the "Service Discovery Instructions",
i.e., the PTR records mapping a service name or a subtype name to a
service instance. A `Service::Description` entry represents the the
SRV and TXT records. A `Service` entry is always associated with a
`Service::Description` and the subtypes of the same service instance
all share the same `Service::Description` entry.
This commit also adds a new method `Host::FindNextService()` and the
public API `otSrpServerHostFindNextService()` which is very flexible
and can be used in different ways. It can be used to iterate over the
full list of services, or over a specific subset of services matching
certain conditions, e.g., iterate over all base services excluding
subtypes, or over all subtypes of an instance, or over all deleted
services, etc. It can also be used to find a specific service with a
given instance and service names.
This commit also simplifies and enhances the logging in `Srp::Server`.
In particular, when a new host is added, we now also log the list of
services being added along with it. Also a change to a `Service` is
only logged if the `Service` is marked as committed. This ensures
that temporary `Service` entries associated with a newly received SRP
update message are not logged (e.g., when an associated temporary
`Host` object is being freed after its content is merged with an
existing `Host` entry).
Finally, this commit adds a test `test_srp_sub_type.py` to cover the
subtype service registration on SRP client and server.
This commit adds new network data service entry definitions to
indicate presence of DNS/SRP servers within the Thread mesh and
provide info about them. Two service TLV formats are added:
`NetworkData::Service::DnsSrpAnycast` indicates that DNS/SRP client on
a device can use the associated anycast address with this service TLV
to reach the DNS/SRP server. The use of anycast address ensures that
the messages are routed to the nearest node which has added such a
service entry in the network data. The service TLV data in this model
contains a one byte sequence number which is used to notify the SRP
clients if they need to re-register with the server(s) (e.g., due
server reset/reboot and/or loss of previous registrations).
`NetworkData::Service::DnsSrpUnicast` directly provides the IPv6
address and port info for a DNS/SRP server which can be included as
part of the service TLV data and/or the server TLV data. Using service
TLV data allows the info about a common infrastructure SRP/DNS server
to be added by multiple BRs. In the case of server TLV, the IPv6
address info can be optionally omitted (i.e. just a port number is
provided) which then causes the associated RLOC/ALOC address of the
node who added the service entry to be used as the server's IPv6
address.
This commit updates the `Srp::Client` to use the new service entries
to discover/select the SRP sever when auto-start mode is enabled. The
client prefers and uses a `DnsSrpAnycast` over `DnsSrpUnicast`
entries. The `Srp::Server` is also updated to publish its info as
`DnsSrpAnycast` entry (using mesh-local address).
This commit also updates the `test_network_data` unit test to cover
the behavior of newly methods which iterate and parse different
service entry formats.
The commit enhances the Routing Manager to learn RA header and
parameters from RA messages initiated from infra interface. This
addresses the issue that the BR may be using different RA header
against another RA daemon which is working on the same infra interface
(Have BR and another RA daemon working on the same interface is common
for Wi-Fi + Thread routers).
We also changed to accept RS messages initiated from the infra
interface: this is for case that multiple Border Routers run on the
same host (as we are trying to support multiple ot-daemons on the same
host).
Simon Lin