This commit introduces a new mechanism for the TREL link to detect and handle discrepancies between the IPv6 address and port used by a TREL peer in a received TREL packet, and the information previously reported by the platform layer (through DNS-SD discovery) for the same peer. Ideally, the platform underlying DNS-SD should detect changes to advertised ports and addresses by peers. However, there are situations where this is not detected reliably. As a received frame over the TREL radio link is processed by the MAC or MLE layers, if the frame passes receive security checks at either layer (indicating it is a secure and authenticated/fresh frame from a valid neighbor), the TREL peer socket address is automatically updated from the received TREL packet info. This ensures the TREL peer table is updated correctly if there are changes to TREL peer addresses of valid Thread neighbors upon rx from such neighbor, increasing the robustness of the TREL link. This commit also introduces a new `otPlatTrel` platform API, `otPlatTrelNotifyPeerSocketAddressDifference()`. The TREL implementation now notifies the platform layer whenever it detects a discrepancy in a TREL peer's socket address, regardless of whether the peer table is automatically updated. This allows the platform layer to take any appropriate action, such as restarting or confirming DNS-SD service resolution query for the peer service instance and/or address resolution query for its associated host name. This commit also adds a new test that validates the newly added behavior, including the auto-update of peer table information and notification of the platform through the new API, triggered by either MLE or MAC messages over the TREL radio link.
OpenThread CLI Example
This example application exposes OpenThread configuration and management APIs via a simple command-line interface. The steps below take you through the minimal steps required to ping one emulated Thread device from another emulated Thread device.
1. Build
$ cd <path-to-openthread>
$ ./script/cmake-build simulation
2. Start node 1
Spawn the process:
$ cd <path-to-openthread>/build/simulation/examples/apps/cli
$ ./ot-cli-ftd 1
Generate, view, and commit a new Active Operational Dataset:
> dataset init new
Done
> dataset
Active Timestamp: 1
Channel: 13
Channel Mask: 0x07fff800
Ext PAN ID: d63e8e3e495ebbc3
Mesh Local Prefix: fd3d:b50b:f96d:722d::/64
Network Key: dfd34f0f05cad978ec4e32b0413038ff
Network Name: OpenThread-8f28
PAN ID: 0x8f28
PSKc: c23a76e98f1a6483639b1ac1271e2e27
Security Policy: 0, onrc
Done
> dataset commit active
Done
Bring up the IPv6 interface:
> ifconfig up
Done
Start Thread protocol operation:
> thread start
Done
Wait a few seconds and verify that the device has become a Thread Leader:
> state
leader
Done
View IPv6 addresses assigned to Node 1's Thread interface:
> ipaddr
fd3d:b50b:f96d:722d:0:ff:fe00:fc00
fd3d:b50b:f96d:722d:0:ff:fe00:c00
fd3d:b50b:f96d:722d:7a73:bff6:9093:9117
fe80:0:0:0:6c41:9001:f3d6:4148
Done
2. Start node 2
Spawn the process:
$ cd <path-to-openthread>/build/simulation/examples/apps/cli
$ ./ot-cli-ftd 2
Configure Thread Network Key from Node 1's Active Operational Dataset:
> dataset networkkey dfd34f0f05cad978ec4e32b0413038ff
Done
> dataset commit active
Done
Bring up the IPv6 interface:
> ifconfig up
Done
Start Thread protocol operation:
> thread start
Done
Wait a few seconds and verify that the device has become a Thread Child or Router:
> state
child
Done
3. Ping Node 1 from Node 2
> ping fd3d:b50b:f96d:722d:7a73:bff6:9093:9117
16 bytes from fd3d:b50b:f96d:722d:558:f56b:d688:799: icmp_seq=1 hlim=64 time=24ms
4. Explore More
See the OpenThread CLI Reference README.md to explore more.