Files
Abtin KeshavarzianandGitHub d1147d62b9 [trel] detect and handle socket addr discrepancy for TREL peers (#10869)
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.
2024-12-18 20:35:58 -08:00
..
2023-06-28 08:54:23 -07:00

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.