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.
This commit fixes incorrect return type in doxygen generated doc by
telling doxygen `OT_TOOL_PRINTF_STYLE_FORMAT_ARG_CHECK` should be
expanded. Doxygen got confused with macros following function
declarations.
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 updates the Multi-AIL Detection feature to operate
independently of the Border Routing Manager. This fundamental change
allows the detector to be enabled/disabled on its own, rather than
being tied to the Border Routing Manager's state.
This change also moves the Multi-AIL detection API into a separate
`openthread/multi_ail_detection.h` header and introduces new APIs to
control the detector independently. Corresponding CLI commands are
also added.
The `test-505-multi-ail-detection.py` is also updated to validate
this new independent behavior. In particular that a device that is
not enabled to act as a BR can independently run multi-AIL detection
and determine whether, if it becomes a BR, it will cause multi-AIL
issues.
Adds two important notes to the main API documentation header to clarify
critical usage rules for all OpenThread APIs.
- The first note states that all API calls and callbacks must be
invoked from the same OS context (e.g., the same thread).
- The second note clarifies the behavior of output parameters when an
API call returns an error.
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.
1. Add OT_WAKEUP_COORDINATOR and OT_WAKEUP_END_DEVICE build
options.
2. Add support for parsing and constructing 802.15.4
Multipurpose frames.
3. Add support for parsing and constructing wake-up
frames.
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.
This commit adds `Utils::VerhoeffChecksum` class along with public OT
APIs and related CLI commands for Verhoeff checksum calculation and
validation. Unit test `test_checksum` is updated to test the new
module.
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 feature allows the RCP to support multiple host stacks on different PANs
by making use of the spinel Interface ID.
Created unit tests for testing multipan feature with multiple ot-instance
support.
Based on Si-Labs PR #8914 by @parag-silabs, but a little different approach.
Instead of handling everything by a single sub-mac instance, multiple
OpenThread instances are created on RCP side that map to different IID.
Thanks to this there are separate data kept for each interface. Platform
is able to determine interface by ot instance pointer passed as an argument
to most of the API functions.
Tx/scan queue was removed as it is possible to request transmission in
parallel, it is up to the platform to decide if it should fail or queue
second tx or it has two radios available.
NOTE:
Platform needs to provide different otRadioFrame of each instance and
the processing needs to take into account the instance being used.
Signed-off-by: Marek Porwisz <marek.porwisz@nordicsemi.no>
New API module from #8668 wasn't added to the high-level Doxygen
menu. This causes the module to show up incorrectly when we import
reference docs into openthread.io.
This commit implements the new TREL model which uses DNS-SD to
discover TREL peers on the network. This implementation replaces the
previous model which relied on link-local multicast.
This commit adds a new set of `otPlatTrel` APIs and callbacks that are
then used by an updated `Trel::Interface` implementation. The
`Trel::Interface` maintains a TREL peer table which is populated from
DNS-SD discovered services. A device supporting TREL registers a new
service to be advertised using DNS-SD with the service name
`_trel._udp`. It also initiates an ongoing DNS-SD browse for the same
service name within the local browsing domain to discover other
devices supporting TREL. `Trel::Interface` encapsulates and send
unicast frames as a unicast UDP message between TREL peers. Broadcast
frames are sent as a group of UDP unicast transmission to a sub-set
of TREL peers.
This commit also adds a new set of public APIs for TREL along with
support for them in CLI:
- APIs for enabling/disabling of TREL operation at run-time.
- Filter mode API which when enabled temporarily drops all the traffic
on the TREL interface (is mainly intended for testing).
- APIs to get the TREL peer table entries.
This commit adds an implementation of the new `otPlatTrel` APIs under
`simulation` platform. This is used for testing. This implementation
emulates a simplified version of DNS-SD mechanism.
A basic implementation of the `otPlatTrel` is also provided under
`posix` platform. However certain functions are tied to mDNS or
DNS-SD library being used on a device and need to be implemented per
project/platform. A set of weak empty functions `trelDnssd{}` are
defined (along with a description of the their expected behavior)
which can be overridden during project/platform integration.
This commit provides the following changes:
* Introduce a new `otPlatCryptoRandom*` API
* Move usage of `mbedtls_entropy_*` and `mbedtls_ctr_drbg_*` out of
ARM PSA enabled platforms
* Stop exposing internal mbedtls contextes for entropy and CTR DRBG
in OpenThread API
Signed-off-by: Lukasz Duda <lukasz.duda@nordicsemi.no>
This commit implements DNS-SD Discovery Proxy.
- Implemented DNS-SD Discovery Proxy functionalities - OT part
- Fixed an memory issue of NameCompressInfo (introduced in #6155 , but
somehow revealed by this commit)
Some implementation details:
- Discovery Proxy subscribes to services/service instances/hosts
through callbacks set by a public OT API. It is up to the platform
mDNS implementation to collect service instance/host information and
notify OT via a public OT API.
- Discovery Proxy can handle DNS browsing of one service or DNS
resolving of one service instance/host. We leave browsing multiple
services or resolving multiple service instances/hosts for future
enhancements if necessary.
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()`.
Abtin Keshavarzian