This commit updates `BorderAgent` modules to directly manage the
registration of mDNS MeshCoP services. Previously, this was the
responsibility of the platform or higher-level code. This behavior is
enabled using `OPENTHREAD_CONFIG_BORDER_AGENT_MESHCOP_SERVICE_ENABLE`
configuration option.
When enabled, the `BorderAgent` module itself will register the
`_meshcop._udp` service name with properly formatted TXT data. As the
state changes, the service registration is updated accordingly.
If the ephemeral key feature is enabled and used, the `BorderAgent`
will also manage the registration of the `_meshcop-e._udp` service.
The implementation allows the service instance name to be configured
in different ways. The Thread specification recommends using a
user-friendly name, such as "<VendorName> <ProductName>". The
name can be set using a newly added configuration option, or
alternatively, using a newly added public API for projects where the
name needs to be set at run-time after device initialization.
This commit also updates `test_border_agent`, validating all the
newly added behaviors related to MeshCoP service registrations.
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 enhances dataset handling:
- Adds `ValidateTlvs()` which parses and validates all known TLVs
within the `Dataset` and checks for any duplicates.
- Introduces a set of `SetFrom()` methods for constructing a `Dataset`
from various types of inputs, e.g., other `Dataset`, TLV sequences,
`DatasetInfo` structures, bytes read from `Message`. Now they
consistently clear the `Dataset` before setting it.
- Adds `WriteTlvsFrom()` to update a `Dataset` replacing/appending a
set of TLVs.
- Adds `AppendTlvsFrom()` to append an already encoded sequence of
TLVs without validating/checking the format.
- Renames `Get/SetSize()` to `Get/SetLength()` for consistency.
- Adds `test_dataset.cpp` unit test for basic `Dataset` validation.
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.