This commit introduces Seeker APIs in OpenThread. An earlier commit
extracted the discovery and candidate selection logic from the `Joiner`
role into a new, standalone `Seeker` module.
The `Seeker` is responsible for performing MLE Discover Scans to find
nearby Joiner Router candidates. It prioritizes these candidates based
on RSSI and steering data (indicating whether the Joiner is preferred)
and manages the list of candidates for connection attempts.
This separation allows the `Seeker` functionality to be utilized
independently of the full `Joiner` role, enabling the development of
custom joining mechanisms over Thread.
A new configuration option `OPENTHREAD_CONFIG_SEEKER_ENABLE` has been
added to control the presence of `otSeeker` APIs.
When `OPENTHREAD_CONFIG_REFERENCE_DEVICE_ENABLE` is active, this
change mandates that the vendor name string MUST begin with the "RD:"
prefix. This ensures that reference devices are clearly and
consistently identifiable through network diagnostic queries.
The enforcement is applied at two levels:
- A compile-time `static_assert` is added to validate the default
`OPENTHREAD_CONFIG_NET_DIAG_VENDOR_NAME` at build time. This uses a
new `constexpr` helper utility `CheckConstStringPrefix()`.
- A runtime check is added to `otThreadSetVendorName()`, which will
now return `OT_ERROR_INVALID_ARGS` if an invalid name is provided
on a reference device build.
All related test configurations (`scan-build`, `toranj`, `nexus`) and
CLI tests are updated to reflect this new requirement and validate
it.
This commit introduces a new script `update-header-guards.py` which
checks for the presence of header guards in `.h` and `.hpp` files and
automatically updates them, standardizing the header guard name format
across the codebase.
The new format for header guards is derived from the full path of the
file. For example, `src/core/common/notifier.hpp` will use
`OT_CORE_COMMON_NOTIFIER_HPP_`. The guard name includes additional
prefixes such as `OT_` or `OPENTHREAD_` to ensure uniqueness.
This new naming format handles cases where the same filename may be used
in different folders, such as the two `heap.hpp` files located in
`src/core/common` and `src/core/utils`.
It also ensures that public and platform OpenThread headers under
`include/openthread` have uniquely distinct header guard names to avoid
conflicts when these headers are included in other projects.
The new script helped identify issues with existing header files that
lacked header guards (e.g., `posix/system.hpp`) or had improper guards
(e.g., `openthread/link_metrics.h`).
This commit also introduces a new check script `check-header-guards` to
validate that all header guards are correctly formatted. This check is
added to the GitHub CI actions to ensure consistency moving forward.
All existing header files have been updated (using the new script)
to apply the new guard name format.
This change adds `EvictActiveCommissioner()` to the Border Agent,
which sends a `LeaderKeepAlive` TMF message with a `StateTlv` of
`kReject` to the Leader, causing the current active commissioner
to be evicted.
The feature is exposed through:
- A new public C API `otBorderAgentEvictActiveCommissioner()`.
- A new CLI command `ba evictcommissioner`.
The entire feature is guarded by a new configuration flag,
`OPENTHREAD_CONFIG_BORDER_AGENT_COMMISSIONER_EVICTION_API_ENABLE`,
which is disabled by default.
This provides an administrator-level tool to remove a stale or
misbehaving commissioner, which is particularly useful when the
commissioner is connected through a different border agent and cannot be
managed locally.
A new test is also added to verify the eviction behavior.
This commit introduces a set of public APIs to allow manipulation
of `otSteeringData`. The new APIs are provided when the configuration
`OPENTHREAD_CONFIG_MESHCOP_STEERING_DATA_API_ENABLE` is enabled.
The internal `SteeringData` is also improved to enhance robustness.
Methods such as `Init()`, `UpdateBloomFilter()` now return an `Error`
to signal failures on invalid arguments (e.g., invalid length)
instead of asserting.
This commit introduces a new feature to parse the MeshCoP service TXT
data from a Border Agent.
The new API `otBorderAgentTxtDataParse()` allows parsing the raw TXT
data into a structured `otBorderAgentTxtDataInfo` object. This can be
used by applications to inspect the capabilities and status of a
discovered Border Agent.
Config `OPENTHREAD_CONFIG_BORDER_AGENT_TXT_DATA_PARSER_ENABLE` controls
this new feature.
The existing test for the Border Agent is updated to validate the new
parser and its output.
Introduces a new `BorderAgentTracker` module to discover and track
Border Agents on the infrastructure link.
The tracker browses for the `_meshcop._udp` mDNS service and maintains
a list of discovered Border Agents. For each discovered service, it
resolves the port, host name, TXT record, and host addresses.
This change also adds new public otBorderAgentTracker APIs,
corresponding `batracker` CLI commands, and a new Nexus test case to
validate the behavior.
This change introduces a `--log-level` option to the `build.sh`
script, allowing the `OPENTHREAD_CONFIG_LOG_LEVEL` to be specified at
build time.
The supported log levels are `NONE`, `CRIT`, `WARN`, `NOTE`, `INFO`,
and `DEBG`. The default level is set to `INFO`.
The CI workflow is updated to test builds with all the supported log
levels.
This commit makes several updates to enable and fix NAT64 unit test
- Enables the NAT64 translator in `toranj` test configs, ensuring
that the `test_nat64` unit test is now covered by the GitHub
Actions CI (under the `toranj` workflow).
- Enable `OPENTHREAD_CONFIG_NAT64_PORT_TRANSLATION_ENABLE` for the POSIX
`toranj` build while disabling it for the simulation build, ensuring
both configurations are built and covered by CI.
- Fixes the `test_nat64` unit test by removing an incorrect
"mapping pool exhausted" step. This step is now invalid as the pool
size is configured to a much larger value (254) via
`OPENTHREAD_CONFIG_NAT64_MAX_MAPPINGS`.
This commit implements `ot::Posix::Dhcp6PdSocket`, which provides the
`otPlatInfraIfDhcp6PdClient*` socket-like APIs for use by the core
`Dhcp6PdClient` module.
The `Posix::Dhcp6PdSocket` is a sub-component of `Posix::InfraNetif`.
This commit resolves a potential unsafe integer conversion warning by
explicitly casting the size of the status sub-TLV to `uint8_t` before
setting the length of the main TLV in
`SendLinkMetricsManagementResponse`.
Additionally, this change enables MLE_LINK_METRICS_SUBJECT_ENABLE`
feature in the `toranj` test configuration, allowing this feature to
be covered under its builds.
This commit implements "Periodic Parent Search" mechanism for FED/REED
devices (FTD children). This enhances and builds upon
the existing parent search feature, which is mainly intended for
MTD children.
An FTD child receives and processes MLE Advertisements from
neighboring routers. The child uses this information to track the
one-way link quality to each router, which is later used to compare
and select potential new parents.
Every "parent search check interval", the FTD child checks to see if
it can select a better parent by evaluating all neighboring routers
based on their link quality information. A router is considered a
suitable parent candidate only if its average RSS exceeds the current
parent's RSS by a margin (`PARENT_SEARCH_RSS_MARGIN`).
Once a candidate is selected, the FTD child sends unicast MLE Parent
Requests to both the candidate and its current parent. This ensures
updated connectivity information is obtained from both before making
a decision. The same set of criteria used to compare candidates
during initial attach are applied during parent switch.
If the attach attempt to the selected candidate fails (e.g., the
router already has the maximum number of children it can support),
the FTD child ensures not to select the same router again until
a "reselect timeout" expires.
This commit also adds the `test-025-fed-parent-search.py test`, which
validates the newly added FTD parent search behavior, including the
mechanisms to attach to a selected router and the reselect timeout.
This commit explicitly enables the `OPENTHREAD_CONFIG_TLS_ENABLE`
macro in `core-toranj-config.h`. This configuration is used to
generate a custom `openthread-mbedtls-config.h` using the `unifdef`
command in `mbedtls/CMakeLists.txt`. Some versions of `unifdef` do
not expand macros first and expect the macro to be defined as a
simple number. This change ensures the build is successful.
This commit introduces a mechanism to check for reachability of
messages forwarded by the BR and send an ICMPv6 Destination
Unreachable error to the sender if needed.
Specifically, if the Border Router (BR) decides to forward an IPv6
message outside the AIL and the message's source address matches a
BR-generated ULA OMR prefix (with low preference), and the
destination is unreachable using this source address, then an ICMPv6
Destination Unreachable message is sent back to the sender.
For example, this situation can occur when a local,
non-infrastructure-derived ULA OMR prefix is published alongside a
`::/0` route (due to discovered PIO/RIO prefixes by the BR). A Thread
mesh device may try to reach addresses beyond the local AIL (e.g.,
the global internet) using the ULA OMR prefix, which would be
unreachable.
This feature is controlled by an OT config flag, enabled by default.
Alternatively, this functionality may be implemented within the
platform layer, in which case the configuration should be disabled.
This commit also adds a test case `test-504-br-icmp-unreach-err.py`
validating the newly added behavior.
This commit improves the `Srp::Client` mechanism for applying random
jitter delays before sending update messages to the server. It now
supports different jitter ranges based on specific triggers. Since
trigger events are often network-wide, potentially causing
simultaneous SRP re-registration from many nodes, longer jitter
intervals are used to distribute the resulting SRP update
transmissions and avoid congestion.
The following triggers are covered:
- Server switch: Client switching to a new server while already
connected to a discovered server. This occurs when a new server
entry appears in Network Data which is preferred over the current
selection.
- Server restart: Client was previously connected to a server that
disappeared from Network Data. Later, the same or a new server is
discovered in Network Data.
- SLAAC address add or remove: This is generally triggered by updates
to SLAAC prefixes in Network Data (e.g., OMR prefix changes).
- First registration after attach:
- If the device is attaching to an established Thread mesh
(e.g., after a reboot or initial pairing), the Network Data it
receives should already include a server entry, leading to a
quick server selection after attach. If server selection occurs
within a short window, a shorter TX jitter is used, allowing the
device to register quickly and become discoverable.
- If server discovery takes longer, a longer TX jitter is used. This
situation can indicate a server/BR starting up or a network-wide
restart of many nodes (e.g., due to a power outage).
This commit introduces `TxJitter` class to manage the requested TX
jitter based on a trigger reason. It tracks the time of the event
that triggered a longer jitter request. If the update message is sent
immediately after the trigger event, the requested maximum jitter is
applied. However, if the update message is sent later, the maximum
jitter is adjusted proportionally to the time elapsed since the
trigger event. If the elapsed time exceeds the requested maximum
jitter interval, the default short jitter is applied to avoid
unnecessary registration delay.
This commit refactors the logic that determines whether to replace the
current Active Dataset with a Pending Dataset upon its delay timer
expiration.
Instead of performing the check within the more general-purpose
`DatasetManager::Save()` method, the logic is now moved directly
into `PendingDatasetManager::HandleDelayTimer()`. This change makes
the code more specific and prevents unintended checks in other
situations where `Save()` is used (e.g., when Active Dataset is
directly set).
The conditions remain the same: The Pending Dataset's Active
Timestamp must be newer, or the Pending Dataset must contain a
different network key.
This commit also adds `test-029-pending-dataset-key-change.py`
to validate the roll-back of Active Timestamp using Pending
Dataset.
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 introduces native mDNS support within the OpenThread
stack, implementing RFC 6762 compliant registration of hosts,
services, and keys. It supports the following functionalities:
- Sending probes to claim names.
- Sending announcements on initial registration and changes.
- Sending "goodbye" announcements when unregistered or upon record
removal.
- Negative responses (NSEC).
- Support for service sub-types and their addition/removal.
- Support for `_services._dns-sd._udp` queries (all service types).
- Responding to queries (including "QU" questions).
- Delay mechanism when responding to multi-question query messages,
ensuring unique answers.
- Providing extra records in the Additional Data section if not
already in the Answer section (e.g., on a PTR query, include SRV
and host AAAA addresses).
- Implementing Known-Answer Suppression.
- Supporting multi-packet queries with known answers in follow-up
messages.
- Rate-limiting record multicasts (once per second).
- Rate-limiting probe responses (once per 250ms).
- Detecting conflicts after probes.
- Limiting the size of emitted responses or probes, breaking into
multiple messages if necessary.
- Detecting self originating messages (sent by mDNS module).
- Support for service browser.
- Support for service resolvers (SRV and TXT records) and IPv4/IPv6
address resolvers for hostnames.
- Introduces smart cache management:
- Passively caches service records for active browsers.
- Passively caches address records for active service resolvers.
- Enables multiple simultaneous browsers/resolvers for the same
service/host.
This commit introduces public `otMdns` OpenThread APIs and related CLI
commands for the mDNS module.
For platform abstraction, `otPlatMdns` APIs are defined in
`mdns_socket.h` (e.g., to send or receive mDNS messages):
- An implementation of the platform APIs is provided for posix.
- Also under the simulation platform, a simplified implementation of the
`otPlatMdns` APIs is provided (intended for testing).
This commit also adds a detailed `test_mdns` unit test, validating
various functionalities and covering potential edge cases.
Implement basic unit tests for tcat to validate BLE secure part.
Additionally align handling of BLE connection states and connection
callbacks.
Signed-off-by: Maciej Baczmanski <maciej.baczmanski@nordicsemi.no>
This commit adds a new mechanism in `BorderAgent` to allow the use of
ephemeral key. New `otBorderAgentSetEphemeralKey` API is added to
allow user to set an ephemeral key. The ephemeral key is used
instead of PSKc from Operation Dataset for a given timeout duration.
New API `otBorderAgentClearEphemeralKey` allows users to cancel the
ephemeral key before its timeout expires. While the timeout interval
is in effect, the ephemeral key can be used only once by an external
commissioner to connect. Once the commissioner disconnects, the
ephemeral key is cleared, and Border Agent reverts to using PSKc.
This commit adds a callback mechanism to signal changes related to the
Border Agent's (BA) use of an ephemeral key. It is invoked when the
BA starts/stops using the key, or when parameters (e.g., port number)
change.
This commit also adds CLI command under `ba ephemeralkey` for the new
APIs along with test script validating the new APIs.
This change makes it possible to build the `posix/platform/infra_if`
module on macOS (and other non-Linux systems). It adds guard checks
`#ifdef __linux__` around the use of `mNetLinkSocket`(used for
network interface state change detection). This allows compilation to
proceed on macOS, though equivalent functionality for detecting netif
change is not yet implemented.
This commit also adds a new `toranj-macos` workflow job to validate
that the code builds successfully with the `posix` platform.
This commit implements address deprecation mechanism in `Slaac` class.
When a prefix is removed from Network Data, its corresponding SLAAC
address is not removed immediately. Instead, it is marked as
deprecated and its "preferred" flag is set to false. After a
deprecation interval (300 seconds), the deprecated address is
removed. If the prefix is re-added to Network Data before the
deprecation time elapses, the SLAAC address is also reinstated.
Since the number of SLAAC address entries is limited, non-deprecated
addresses are prioritized. This means that if a new entry is required
for a new prefix, the earliest deprecating entry can be evicted to
accommodate the new entry.
The `Slaac` module keeps track of the associated Domain IDs for
deprecating SLAAC prefixes, even if the related Prefix TLV has
already been removed from the Network Data. This information is used
during external route lookup in `NetworkData::Leader::RouteLookup()`
if a deprecating SLAAC address is used as the source address in
an outbound message, ensuring that the message is not dropped and
can be delivered.
This commit also adds a detailed test `test-027-slaac-address.py`
validating various behaviors of SLAAC module.
This commit adds a public OT API to generate hex dump output line by
line. This function is then used for both `LogDump{}()` and frame
capture output by CLI `promiscuous` command (removing repeated
similar code) and harmonize the hex dump outputs.
This commit simplifies how the `Netif` unicast and multicast addresses
that use the mesh-local prefix are updated when the mesh-local prefix
is changed.
The `Netif::UnicastAddress` class now includes a `mMeshLocal` flag,
which is set for all mesh-local addresses (RLOCs, ALOCs, and ML-EID).
When the mesh-local prefix is changed, `Mle` will inform `ThreadNetif`
to apply the new prefix. `ThreadNetif` will then update all of the
assigned unicast addresses that are marked as mesh-local, as well as
all of the subscribed mesh-local prefix-based multicast addresses
(such as link-local or realm-local All Thread Nodes addresses). The
`Netif` class first signals the removal of the previous address based
on the old prefix, and then the addition of the new address with the
new mesh-local prefix.
This change simplifies the code, in particular the modules such as
`Commissioner`, `BorderAgent` and `BackboneRouter::Local`, which need
to manage specific ALOC addresses. These modules no longer need to be
informed when the mesh-local prefix is changed to update their
address, as it will be done by the `Netif` class directly.
This commit adds a build configuration flag for the feature to set and
get device properties, which are then used to calculate the local
leader weight on a device. The feature is enabled by default on
Thread 1.3.1 or later. The new configuration flag allows OpenThread
project integrators to enable this feature on earlier versions if
desired.
This commit removes the unnecessary Doxygen-style documentation of
used configuration options from toranj config header files. This
makes the test-specific config header simpler and avoids confusion
with the main config parameters documentation, which is included in
the corresponding `src/config/<name>.h` header files.
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 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 adds `MLE_PARENT_RESPONSE_CALLBACK_API_ENABLE` config
which enables support for `otThreadRegisterParentResponseCallback()`
API. This API registers a callback to notify user of received
Parent Response message(s) during attach. This API is mainly intended
for debugging and therefore is is disabled by default. It is enabled
in `toranj-config` so to validate the code (i.e. it causes no build
errors) during CI GitHub action runs.
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 updates cli-based `toranj` test framework and adds new
test-cases using this framework. The new test-cases re-implement all
the current ncp/wpantund based ones that cover OpenThread core
behavior (including the multi-radio and trel test-cases). Some of
the tests are enhanced (e.g. adding new checks) and some related
tests are combined into a single script.
This commit also updates the `toranj` CI GitHub workflow to use the
new cli-based model for multi-radio and trel (removing the ncp
based versions).
This commit updates the `RoutingManager` to allow domain prefix from
Network Data to also be considered during OMR selection. In
particular:
- `IsValidOmrPrefix(config)` now accepts prefixes with `mDp` flag.
- `OmrPrefix` now tracks whether the prefix is domain prefix.
- When appending RIO in RA message, the domain prefix is always
excluded (independent of whether or not it is the current favored
OMR prefix).
This commit also updates the `test_routing_manager` unit test to add
a test case checking behavior of `RoutingManager` when a domain prefix
is selected as the favored OMR.
This commit implements delay-aware queue management. When enabled the
device will monitor time-in-queue of messages in the direct tx queue
and if it is lager than specified thresholds it updates ECN flag
(if message indicates it is ECN-capable) and/or drop the message. This
mechanism is applied to IPv6 messages on the first device that sends
the message into Thread mesh and also on intermediate routers that are
forwarding the message (e.g., as a "mesh lowpan fragment" frame). On an
intermediate router when forwarding the fragments of a message, if any
fragment is dropped by the queue management policy, all subsequent
fragments will also be dropped.
In particular, this commit contains the following:
- Adds `DecompressEcn()` and `MarkCompressedEcn()` in `Lowpan` class
to decompress or update the ECN field in a compressed IPHC header
(unit test `test_lowpan` is also updated to test the new methods).
- Adds `UpdateEcnOrDrop()` which implements the main queue management
logic. This method is used when preparing next direct tx message. It
decides whether to keep the message as is, update ECN on it or drop
it.
- Updates `EvictMessage()` to first apply the queue management rule
to see if any message can be dropped before using the eviction
logic based on message priority.
- Updates and reuses the `FragmentPriorityList` to track whether
queue management dropped any of the fragments of same message so
to also drop any subsequent ones.
- Updates `LogMessage()` to log when a message is dropped by
queue-management or when ECN is marked on a message.
This commit contains smaller enhancements in `RoutingManager `
and `Prefix/RouteInfoOption`.
This commit changes how the options are added in a message so that we
directly construct the option in the message buffer (instead of
creating it separately and then copying the bytes).
It also changes `RouteInfoOption::IsValid()` to validate that the
option length can fit the specified prefix length.
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.
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.
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 `OPENTHREAD_CONFIG_LOG_PREPEND_UPTIME` config to
prepend the current uptime (as "[x days] hh::mm::ss.mmmm") to the
OpenThread log messages.
This commit adds a new module `Uptime` which tracks the number of
milliseconds since OpenThread stack initialization as an `uint64_t`
value. It also adds public OT APIs to get the current uptime value
(either as the number of milliseconds or in human-readable string
format like "2 days 12:45:12.762"). A CLI `uptime` command is also
added. This feature can be enabled using the newly added config
option `OPENTHREAD_CONFIG_UPTIME_ENABLE` (or the related CMake
`OT_UPTIME` option).
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`.
Abtin Keshavarzian