This commit updates the `Srp::Server` class to correctly handle the
case where a service is registered with a dot character in its
service instance name. The first label in a service instance name is
intended as a user-friendly name and can contain dot characters
(it has fewer restrictions than other labels in a DNS name).
In particular, this commit contains the following changes:
- The `PtrRecords::ReadPtrName()` method is used in `Srp::Server` to
read and validate the first label and the rest of the labels
separately. This also validates the format of the parsed PTR
record.
- The `Service::Description` class now remembers the instance label in
addition to the full instance name. This allows the instance label
to be easily retrieved.
- The `Dns::Name::ReadName()` method is updated to only verify that
the labels after the first label do not contain any dot characters.
This allows it to be used to read instance service names.
- The tests are updated to validate the behavior of the SRP server
when the instance label contains a dot character.
This commit updates the unit tests that emulate the radio platform API
to define `otPlatRadioGetCaps()`, which returns the ACK_TIMEOUT and
CSMA capabilities. This is to avoid having CSMA being implemented by
the `SubMac`, which then uses the microsecond timer that is not
emulated in the unit test platform.
It also updates the `InitTest()` function to clear the radio platform
variable `sRadioTxOngoing`. This is to avoid the possible
(though unlikely) situation where an earlier test finishes in the
middle of a transmission, causing an extra `TxDone` event in the
following test.
This commit updates SRP client and server to support short variant
format for Update Lease Option. The short variant includes the lease
interval only (4 bytes) vs the long variant which includes both lease
and key lease intervals (8 bytes). Client and server can parse and
process both formats in received messages. Client by default uses the
long variant. Server will also use the long variant in its response
unless the request message uses the short variant format, i.e., if
the client uses the short variant, the server will also respond using
the short variant. This behavior is required by the latest Update
Lease draft.
This commit also updates `test_srp_server` unit test, adding a new
test-case to validate the behavior of client and server when short
Update Lease Option is used. A new method (intended for testing and
and only available under `REFERENCE_DEVCIE` config) is added which
configures the client to use the short variant format changing the
default behavior.
This commit updates `PrepareService()` functions to `memset` the
`Service` instance to zero before populating its fields. This ensures
that all new properties (e.g., recently added `mLease`/`mKeyLease`)
are set to zero and use the corresponding default value.
According to Thread 1.3.0 Section 4.7.1.3, router synchronization
after reset requires the multicast link request message to be
retransmitted until a response is received, or the maximum
transmission limit has been reached. If the router was a leader or had
more than 5 children prior to reset, it MUST be retransmitted as a
critical message. Each multicast retransmission of an MLE Message on a
TL1 or TL2 Link must be delayed by MLE_MULTICAST_RETRANSMISSION_DELAY
multiplied by a random value between 0.9 and 1.1 with a resolution of
at least 1 ms.
This commit implements the above requirement. With this requirement,
in the cases when a router is reset and there is no other router to
respond to the link request then it takes longer time for the router
to join thread network. Thus some test cases are modified to allow
longer router sync time in such cases.
This commit adds a unit test for `Srp::Server` (which also covers
`Srp::Client`) building a foundation for writing tests covering edge
cases of SRP server and its interaction with platform "update handler"
callback and SRP client.
For example, the test validates behavior of SRP sever, when
"update handler" accepts, rejects, or ignores (waits for timeout)
the received SRP updates. The test also validates that all heap
allocated objects (used by SRP sever) are properly freed under
different scenarios (validating that there is no heap object leak).