This commit adds "Fast Start Mode" feature for SRP server. This
feature is designed for scenarios where a device, often a mobile
device, needs to act as a provisional SRP server (e.g., functioning
as a temporary Border Router). The SRP server function is enabled
only if no other Border Routers are already providing the SRP
service within the Thread network. A common use case is a mobile
device joining a Thread network where it may be the first, or only,
BR. Importantly, Fast Start Mode allows the device to quickly start
its SRP server functionality upon joining the network, allowing other
Thread devices to quickly connect and register their services without
the typical delays associated with standard Border Router
initialization and SRP server startup (using NetData Publisher).
This commit adds a new mechanism in `RoutingManager` to track the
duration since a router is first discovered. This information is now
provided in `otBorderRoutingRouterEntry`, and the CLI `br routers`
command is updated to include this information for each router.
To enable tracking of longer durations, `Uptime` is used, which tracks
milliseconds since the start of `ot::Instance` as a `uint64_t` value.
`TimerMilli::GetNow()` is not suitable for this purpose because it
utilizes `uint32_t` intervals, which would limit the maximum
trackable time to roughly 49 days due to potential overflow.
This commit implements a generic discovery proxy in the DNS-SD server.
It uses a set of newly added `otPlatDnssd` platform DNS-SD(mDNS) APIs
to start or stop browsers, SRV/TXT resolvers, and IPv6/IPv4 address
resolvers. These APIs closely match the native OpenThread mDNS
implementation.
OpenThread DNS-SD's existing `QueryCallback` mechanism, enabling
customized discovery proxy implementations, remains supported.
This commit includes a comprehensive unit test. This test validates
the discovery proxy's behavior, covering: standard use cases, request
timeout, s hared resolver/browser usage for multiple queries with the
same name, filtering of invalid addresses, and various edge cases.
Updates the `Dnssd` module to allow it use
- Either the native OT mDNS implementation
- Or use the platform `otPlatDnssd` APIs (delegated to platform)
Also adds `OPENTHREAD_CONFIG_MULTICAST_DNS_AUTO_ENABLE_ON_INFRA_IF`
for mDNS module to be automatically enabled/disabled on the same
infra-if used for border routing based on infra-if state.
This commit adds a generic SRP Advertising Proxy implementation to
OpenThread core, which uses a set of newly defined `otPlatDnssd`
platform APIs for DNS-SD (mDNS) support on infrastructure network on
a Border Router.
`Srp::Server` provides `ServiceUpdateHandler` callback mechanism that
allows platforms to implement their own advertising proxy function.
While this is still supported, the new generic advertising proxy
implementation makes it easier to port and support the proxy function
on new platforms. The platform needs to provide the DNS-SD platform
APIs, which are designed to be simple and easy to implement.
The `AdvertisingProxy` directly interacts with `Srp::Server` and its
registered `Host` and `Service` entries, tracking whether an entry
has been successfully advertised, is currently being advertised, or
has been replaced by a new registration.
The `AdvertisingProxy` ensures that consecutive SRP updates for the
same host or service are committed on the server in the order they
are received, even if their advertisements are finished in a
different order. This is important for SRP Replication support, as
the server may receive a large number of SRP updates back-to-back for
the same host.
The `AdvertisingProxy` will also register key records for SRP host and
service instance names. This will keep the claim on the name of a
removed entry while its key lease is not expired. It is also used
when an SRP host registration has no off-mesh routable address.
This commit adds a detailed unit test `test_srp_adv_proxy` that
validates the `AdvertisingProxy` under many scenarios. The test
covers a range of cases, including delayed registration callbacks and
timeouts, new registrations replacing outstanding advertisements,
platform DNS-SD state changes and failures, host address changes
adding/removing OMR addresses.
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 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 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 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 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 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`.
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 removes application library CLI/NCP dependency on platform
layer UART APIs. Instead, application layer provides callbacks sending
CLI/NCP data.
With this change, platforms with native support for formatted output
can simply implement the CLI output callback with something like
`vprintf()`.
This PR includes the initial implementation of the SRP server
defined in https://tools.ietf.org/html/draft-ietf-dnssd-srp-07.
- SRP server Service TLV propagation: Includes only the 2-bytes
dynamic listening port in the Server TLV.
- SRP request processing (parsing & validation)
- LEASE & KEY-LEASE management
- SIG(0) verification
- Interface for advertising proxy
- CLI commands for testing
- Support removing indivitual SRP service
This commit adds support for SRP (Service Registration Protocol)
client in OpenThread. The implementation allows a user to provide host
info (host name and a list of host IPv6 addresses) along with a list
of services to be registered with an SRP server. Services and/or host
addresses can be added or removed during operation of client.
Users can get the list of services and host info and their current
state (indicating, for example, if service is registered with server,
being registered or being removed, etc). Users can also provide a
callback to get notified whenever there is change or an error.
When there is a new request (e.g., a new service is added/removed)
that requires an update, the SRP client will wait for a short delay
before preparing and sending an SRP update message to server. This
allows user to provide more changes that are then all sent in the same
update message. The implementation handles retries in case of
different errors and failures. An exponentially increasing retry wait
interval (with configurable min, max, and growth factor) is
implemented.
The implementation also manages the lease renew time for each service
and refreshes (re-registers) services with server before lease is
expired. It supports "opportunistic early refresh" mechanism such that
when sending an SRP update, the services that are not yet expired but
are close, are allowed to refresh early and are included in the SRP
update. This helps place more services on the same lease refresh
schedule reducing number of messages sent to the SRP server. This
behavior (whether to allow early refresh or not, and its related
parameters) can be controlled through a set of OT config definitions.
This commit adds a new module `DatasetUpdater` which provides
easy-to-use APIs for user to request an update to any component (a
subset of components) in Operational Dataset of the Thread network.
The change can be requested from any node in the network. The
implementation uses `MGMT_PENDING_SET` command and takes care of
preparing the Pending Dataset and updating timestamps and monitoring
for the Dataset to be updated and possibly retrying. It reports the
outcome (success or failure status) back to the user in a callback.
This commit also updates the `ChannelManager` module is to use the
`DatasetUpdater` to change the channel.
* add a CLI command for getting the network interface name and index
On some platform (mostly BSDs), we do not have the option to specify
the tunnel name, although most of those platforms do have a way to dynamically
obtain a unique interface name if desired. Add a CLI command -- only enabled
on platforms that have PLATFORM_NETIF enabled -- that will return the
name of the tunnel interface, as well as it's index. Both are useful in doing
automated tests on non-Linux systems.
* remove OPENTHREAD_CONFIG_PLATFORM_NETIF_ENABLE from the "check" scripts
This option really only applies to the POSIX "management" applications
(ot-daemon, ot-ctl), and not to the core radio or simulation component
builds (ot-cli, etc).
My other change adds a command ("netif") that is only useful when the
netif code is enabled, and that only happens when the netif code is linked,
which is only in those "management" utilities. Turning this setting off
allows the tests to pass, with no impact to the functionality previously
tested. But if this setting remains on, then my new code creates a
dependency that cannot be resolved outside the management applications.
In Thread 1.2, it is possible to receive an IEEE 802.15.4-2015
packet. Per specification, receiver should acknowledge this packet
with an IEEE 802.15.4-2015 ACK(Enh-ACK). This Enh-ACK can include
header IE with it and requires security enabled bit in FCF be set to
true. It is impractical for the host to generate the Enh-ACK and send
to RCP for transmission within AIFS time(192us). So RCP should prepare
the Enh-ACK by itself, which requires it to fill in the frame counter
and do the encryption/authentication. This commit tries to address the
need of transmission security/authentication by including the
following changes,
- Move Key ID mode 1 AES-CCM* related functions from MAC layer to
SubMac layer, which is mirrored in RCP.
- Distribute the MAC key and MAC key ID to RCP in posix app using
newly added spinel properties.
- Make it possible for radio(either in radio driver or hardware) to do
transmission AES-CCM* if the platform supports by adding radio
capability OT_RADIO_CAPS_TRANSMIT_SEC.
- Enable this for RCP mode on simulation platform.
