Crea una rete Thread con schede nRF52840 e OpenThread

1. Introduzione

OpenThread rilasciato da Google è un'implementazione open source del protocollo di rete Thread®. Google Nest ha rilasciato OpenThread per rendere la tecnologia utilizzata nei prodotti Nest ampiamente disponibile agli sviluppatori, in modo da accelerare lo sviluppo di prodotti per la casa connessa.

La specifica Thread definisce un protocollo di comunicazione wireless affidabile, sicuro e a basso consumo basato su IPv6 per le applicazioni domestiche. OpenThread implementa tutti i livelli di rete Thread, inclusi IPv6, 6LoWPAN, IEEE 802.15.4 con sicurezza MAC, Mesh Link Establishment e Mesh Routing.

In questo Codelab, programmerai OpenThread su hardware reale, creerai e gestirai una rete Thread e trasmetterai messaggi tra i nodi.

Obiettivi didattici

• Creazione e flashing dei file binari dell'interfaccia a riga di comando OpenThread sulle schede di sviluppo
• Creazione di un RCP costituito da una macchina Linux e una scheda di sviluppo
• Comunicazione con un RCP utilizzando OpenThread Daemon e ot-ctl
• Gestione manuale dei nodi Thread con GNU Screen e la CLI OpenThread
• Messa in servizio sicura dei dispositivi su una rete Thread
• Come funziona il multicast IPv6
• Passaggio di messaggi tra nodi Thread con UDP

Che cosa ti serve

Hardware:

• 3 schede di sviluppo Nordic Semiconductor nRF52840
• 3 cavi da USB a micro USB per collegare le schede
• Un computer Linux con almeno 3 porte USB

Software:

• GNU Toolchain
• Strumenti a riga di comando Nordic nRF5x
• Software Segger J-Link
• OpenThread
• Git

2. Per iniziare

Simulazione OpenThread

Prima di iniziare, ti consigliamo di completare il codelab sulla simulazione di OpenThread per acquisire familiarità con i concetti di base di Thread e con la CLI di OpenThread.

Terminali della porta seriale

Dovresti sapere come connetterti a una porta seriale tramite un terminale. Questo codelab utilizza GNU Screen e fornisce una panoramica dell'utilizzo, ma è possibile utilizzare qualsiasi altro software terminale.

Macchina Linux

Questo Codelab è stato progettato per utilizzare una macchina Linux basata su i386 o x86 come host per un dispositivo Radio Co-Processor (RCP) Thread e per eseguire il flashing di tutte le schede di sviluppo Thread. Tutti i passaggi sono stati testati su Ubuntu 14.04.5 LTS (Trusty Tahr).

Schede Nordic Semiconductor nRF52840

Questo codelab utilizza tre schede nRF52840 PDK.

Importante:assicurati che le schede abbiano alimentazione sufficiente. Non utilizzare uno splitter per porte USB per collegarli alla macchina Linux e disattiva qualsiasi funzionalità di sospensione per la macchina Linux. Le schede con alimentazione insufficiente potrebbero comportarsi in modo imprevisto.

Installa SEGGER J-Link

Utilizziamo SEGGER J-Link per programmare le schede nRF52840, che hanno moduli JTAG integrati. Installa questo pacchetto sulla tua macchina Linux.

Scarica il pacchetto software e documentazione J-Link

Scarica il pacchetto appropriato per la tua macchina e installalo nella posizione corretta. Su Linux è /opt/SEGGER/JLink.

Installa gli strumenti a riga di comando nRF5x

Gli strumenti a riga di comando nRF5x ti consentono di caricare i file binari OpenThread sulle schede nRF52840. Installa la build nRF5x-Command-Line-Tools-<OS> appropriata sulla tua macchina Linux.

Scaricare gli strumenti a riga di comando nRF5x

Inserisci il pacchetto estratto nella cartella principale ~/

Nota: gli strumenti a riga di comando nRF5x non supportano le architetture ARM, pertanto le schede nRF52840 non possono essere programmate da macchine Linux basate su ARM, come Raspberry Pi 3B.

Installare ARM GNU Toolchain

Per la creazione viene utilizzata la toolchain GNU ARM.

Scarica l'archivio portatile della toolchain GNU ARM

Ti consigliamo di inserire l'archivio estratto in /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/ sul tuo computer Linux. Segui le istruzioni nel file readme.txt dell'archivio per l'installazione.

(Facoltativo) Installare lo schermo

Screen è un semplice strumento per accedere ai dispositivi connessi tramite una porta seriale. Questo codelab utilizza Screen, ma puoi utilizzare qualsiasi applicazione terminale della porta seriale che preferisci.

$ sudo apt-get install screen

3. Clonare repository

OpenThread

Clona e installa OpenThread. I comandi script/bootstrap assicurano che la toolchain sia installata e che l'ambiente sia configurato correttamente:

$ mkdir -p ~/src
$ cd ~/src
$ git clone --recursive https://github.com/openthread/openthread.git
$ cd openthread
$ ./script/bootstrap

Crea il daemon OpenThread:

$ script/cmake-build posix -DOT_DAEMON=ON

Ora puoi creare e caricare OpenThread sulle schede nRF52840.

4. Configurare RCP Joiner

Crea e carica

Crea l'esempio OpenThread nRF52840 con funzionalità Joiner e USB nativa. Un dispositivo utilizza il ruolo di Joiner per essere autenticato e commissionato in modo sicuro su una rete Thread. La funzionalità USB nativa consente l'utilizzo di USB CDC ACM come trasporto seriale tra nRF52840 e l'host.

Pulisci sempre prima il repository dalle build precedenti eseguendo rm -rf build.

$ cd ~/src
$ git clone --recursive https://github.com/openthread/ot-nrf528xx.git
$ cd ot-nrf528xx
$ script/build nrf52840 USB_trans

Per ulteriori informazioni sulla creazione e la configurazione di OpenThread, consulta Creare OpenThread.

Vai alla directory con il binario RCP OpenThread e convertilo in formato esadecimale:

$ cd ~/src/ot-nrf528xx/build/bin
$ arm-none-eabi-objcopy -O ihex ot-rcp ot-rcp.hex

Collega il cavo USB alla porta di debug micro USB accanto al pin di alimentazione esterno sulla scheda nRF52840, quindi collegalo alla macchina Linux. Imposta l'interruttore nRF power source (Alimentazione nRF) sulla scheda nRF52840 su VDD. Quando è collegato correttamente, il LED5 è acceso.

Se questa è la prima scheda collegata alla macchina Linux, viene visualizzata come porta seriale /dev/ttyACM0 (tutte le schede nRF52840 utilizzano ttyACM per l'identificatore della porta seriale).

$ ls /dev/ttyACM*
/dev/ttyACM0

Prendi nota del numero di serie della scheda nRF52840 utilizzata per l'RCP:

Vai alla posizione degli strumenti a riga di comando nRFx e carica il file esadecimale RCP di OpenThread sulla scheda nRF52840 utilizzando il numero di serie della scheda. Tieni presente che se ometti il flag --verify, vedrai un messaggio di avviso che ti informa che la procedura di flash può non riuscire senza errori.

$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924  --verify --chiperase --program \
       ~/src/ot-nrf528xx/build/bin/ot-rcp.hex --reset

In caso di esito positivo, viene generato il seguente output:

Parsing hex file.
Erasing user available code and UICR flash areas.
Applying system reset.
Checking that the area to write is not protected.
Programing device.
Applying system reset.
Run.

Etichetta la scheda "RCP" in modo da non confondere i ruoli della scheda in un secondo momento.

Connettersi alla porta USB nativa

Poiché la build RCP OpenThread consente l'utilizzo di USB CDC ACM nativo come trasporto seriale, devi utilizzare la porta nRF USB sulla scheda nRF52840 per comunicare con l'host RCP (computer Linux).

Scollega l'estremità micro USB del cavo USB dalla porta di debug della scheda nRF52840 flashata, quindi ricollegala alla porta micro USB nRF USB accanto al pulsante RESET. Imposta l'interruttore nRF power source su USB.

Nota:quando la scheda nRF52840 è collegata correttamente a un host tramite la porta USB nRF, nessuno degli indicatori LED si accende, anche se la scheda è operativa.

Avvia il daemon OpenThread

Nel design RCP, utilizza OpenThread Daemon per comunicare con il dispositivo Thread e gestirlo. Avvia ot-daemon con il flag dettagliato -v in modo da visualizzare l'output del log e verificare che sia in esecuzione:

$ cd ~/src/openthread
$ sudo ./build/posix/src/posix/ot-daemon -v \
    'spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=460800'

Se l'operazione va a buon fine, ot-daemon in modalità dettagliata genera un output simile al seguente:

ot-daemon[12463]: Running OPENTHREAD/thread-reference-20200818-1938-g0f10480ed; POSIX; Aug 30 2022 10:55:05
ot-daemon[12463]: Thread version: 4
ot-daemon[12463]: Thread interface: wpan0
ot-daemon[12463]: RCP version: OPENTHREAD/thread-reference-20200818-1938-g0f10480ed; SIMULATION; Aug 30 2022 10:54:10

Lascia aperta questa finestra del terminale in modo che i log di ot-daemon possano essere visualizzati.

Utilizza ot-ctl per comunicare con il nodo RCP. ot-ctl utilizza la stessa CLI dell'app CLI OpenThread. Pertanto, puoi controllare i nodi ot-daemon allo stesso modo degli altri dispositivi Thread simulati.

In una seconda finestra del terminale, avvia ot-ctl:

$ sudo ./build/posix/src/posix/ot-ctl
>

Controlla state del nodo 2 (il nodo RCP) con cui hai iniziato ot-daemon:

> state
disabled
Done

5. Configurare i FTD

Gli altri due nodi Thread utilizzati in questo Codelab sono Full Thread Devices (FTD) con il design standard System-on-Chip (SoC). Un dispositivo funge da Commissario per autenticare e configurare in modo sicuro i dispositivi sulla rete. L'altro dispositivo funge da Joiner che il Commissioner può autenticare alla rete Thread.

Crea e carica

Crea l'esempio FTD di OpenThread per la piattaforma nRF52840, con i ruoli di Commissario e Joiner abilitati:

$ cd ~/src/ot-nrf528xx
$ rm -rf build
$ script/build nrf52840 USB_trans -DOT_JOINER=ON -DOT_COMMISSIONER=ON

Idealmente, dovresti creare OpenThread con solo la funzionalità desiderata abilitata. Ad esempio, FTD Joiner utilizzerebbe solo l'opzione JOINER=1. Per facilità d'uso in questo codelab, crea una singola immagine con entrambi i ruoli in modo che possa essere utilizzata per entrambi i FTD.

Vai alla directory con il binario della CLI OpenThread Full Thread Device (FTD) e convertilo in formato esadecimale:

$ cd ~/src/ot-nrf528xx/build/bin
$ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex

Collega il cavo USB alla porta micro USB accanto al pin di alimentazione esterno sulla scheda nRF52840, quindi collegalo alla macchina Linux. Se il RCP è ancora collegato alla macchina Linux, questa nuova scheda dovrebbe essere visualizzata come porta seriale /dev/ttyACM1 (tutte le schede nRF52840 utilizzano ttyACM per l'identificatore della porta seriale).

$ ls /dev/ttyACM*
/dev/ttyACM0  /dev/ttyACM1

Come prima, annota il numero di serie della scheda nRF52840 utilizzata per il test funzionale del dispositivo:

Vai alla posizione degli strumenti da riga di comando nRFx e carica il file esadecimale FTD della CLI OpenThread sulla scheda nRF52840 utilizzando il numero di serie della scheda:

$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
       ~/src/ot-nrf528xx/build/bin/ot-cli-ftd.hex --reset

Etichetta la bacheca "Commissario".

Connettersi alla porta USB nativa

Poiché la build FTD di OpenThread consente l'utilizzo di USB CDC ACM nativa come trasporto seriale, devi utilizzare la porta nRF USB sulla scheda nRF52840 per comunicare con l'host RCP (macchina Linux).

Scollega l'estremità micro USB del cavo USB dalla porta di debug della scheda nRF52840 flashata, quindi ricollegala alla porta micro USB nRF USB accanto al pulsante RESET. Imposta l'interruttore nRF power source su USB.

Nota:quando la scheda nRF52840 è collegata correttamente a un host tramite la porta USB nRF, nessuno degli indicatori LED si accende, anche se la scheda è operativa.

Verifica build

Verifica che la build sia stata eseguita correttamente accedendo alla CLI OpenThread utilizzando GNU Screen da una finestra del terminale.

$ screen /dev/ttyACM1

Nella nuova finestra, premi Invio sulla tastiera alcune volte per visualizzare il prompt della CLI OpenThread >. Visualizza l'interfaccia IPv6 e controlla gli indirizzi:

> ifconfig up
Done
> ipaddr
fe80:0:0:0:1cd6:87a9:cb9d:4b1d
Done

Usa Ctrl+A →

d per scollegarti dalla schermata della CLI di FTD Commissioner e tornare al terminale Linux in modo che la scheda successiva possa essere flashata. Per rientrare nella CLI in qualsiasi momento, utilizza screen -r dalla riga di comando. Per visualizzare un elenco delle schermate disponibili, utilizza screen -ls:

$ screen -ls
There is a screen on:
        74182.ttys000.mylinuxmachine        (Detached)
1 Socket in /tmp/uscreens/S-username.

Configurare FTD Joiner

Ripeti la procedura precedente per programmare la terza scheda nRF52840 utilizzando la build ot-cli-ftd.hex esistente. Al termine, assicurati di ricollegare la scheda al PC utilizzando la porta USB nRF e di impostare l'interruttore nRF power source su VDD.

Se gli altri due nodi sono collegati alla macchina Linux quando viene collegata questa terza scheda, dovrebbe essere visualizzata come porta seriale /dev/ttyACM2:

$ ls /dev/ttyACM*
/dev/ttyACM0  /dev/ttyACM1  /dev/ttyACM2

Etichetta la bacheca "Joiner".

Quando esegui la verifica utilizzando Screen, anziché creare una nuova istanza di Screen dalla riga di comando, ricollegati a quella esistente e crea una nuova finestra al suo interno (quella che hai utilizzato per il commissario FTD):

$ screen -r

Crea la nuova finestra all'interno di Screen con Ctrl+a → c.

Viene visualizzato un nuovo prompt della riga di comando. Accedi alla CLI OpenThread per il FTD Joiner:

$ screen /dev/ttyACM2

In questa nuova finestra, premi Invio sulla tastiera alcune volte per visualizzare il prompt della CLI OpenThread >. Visualizza l'interfaccia IPv6 e controlla gli indirizzi:

> ifconfig up
Done
> ipaddr
fe80:0:0:0:6c1e:87a2:df05:c240
Done

Ora che la CLI FTD Joiner si trova nella stessa istanza di Screen di FTD Commissioner, puoi passare da una all'altra utilizzando Ctrl+a → n.

Usa Ctrl+A →

d in qualsiasi momento per uscire da Schermo.

6. Configurazione della finestra del terminale

In futuro, passerai spesso da un dispositivo Thread all'altro, quindi assicurati che siano tutti attivi e facilmente accessibili. Finora abbiamo utilizzato Screen per accedere ai due FTD e questo strumento consente anche di dividere lo schermo nella stessa finestra del terminale. Utilizzalo per vedere come un nodo reagisce ai comandi emessi su un altro.

Idealmente, dovresti avere quattro finestre a disposizione:

1. Servizio / log di ot-daemon
2. RCP Joiner tramite ot-ctl
3. FTD Commissioner tramite la CLI OpenThread
4. FTD Joiner tramite la CLI OpenThread

Se vuoi utilizzare la tua configurazione o il tuo strumento per la porta seriale / il terminale, puoi passare al passaggio successivo. Configura le finestre del terminale per tutti i dispositivi nel modo più adatto alle tue esigenze.

Utilizzare Screen

Per facilità d'uso, avvia una sola sessione di Screen. Dovresti già averne uno dalla configurazione di entrambi i FTD.

Tutti i comandi all'interno di Screen iniziano con Ctrl+A.

Comandi di base dello schermo:

Ricollegarsi alla sessione Screen (dalla riga di comando)	screen -r
Uscire dalla sessione di Screen	Ctrl+a → d
Crea una nuova finestra all'interno della sessione Schermo	Ctrl+a → c
Passare da una finestra all'altra nella stessa sessione di Screen	Ctrl+a → n (avanti)Ctrl+a → p (indietro)
Termina la finestra corrente nella sessione Screen	Ctrl+a → k

Se ti perdi nella configurazione, continua a chiudere le finestre di Screen con Ctrl+a → k finché non ne rimangono. Poi avvia una nuova sessione di Screen e crea nuove finestre per ogni dispositivo.

Schermo diviso

Con Screen, puoi dividere il terminale in più finestre:

Ai comandi in screen si accede utilizzando Ctrl+a. Ogni comando deve iniziare con questa combinazione di tasti di accesso.

Se hai seguito esattamente il Codelab, dovresti avere due finestre (FTD Commissioner, FTD Joiner) nella stessa istanza di Screen. Per dividere lo schermo tra le due persone, inserisci prima la sessione di Screen esistente:

$ screen -r

Devi utilizzare uno dei dispositivi FTD. Segui questi passaggi in Screen:

1. Ctrl+a → S per dividere la finestra orizzontalmente
2. Ctrl+a → Tab per spostare il cursore nella nuova finestra vuota
3. Ctrl+a → n per passare alla finestra successiva
4. Se è uguale a quella della finestra in alto, premi Ctrl+a → n di nuovo per visualizzare l'altro dispositivo FTD.

Ora sono entrambi visibili. Passa da uno all'altro utilizzando Ctrl+A → Tab. Per evitare confusione, ti consigliamo di rinominare ogni finestra con Ctrl+a → A.

Utilizzo avanzato

Per dividere ulteriormente lo schermo in quadranti e visualizzare i log di ot-daemon e RCP Joiner ot-ctl, questi servizi devono essere avviati nella stessa istanza di schermo. Per farlo, arresta ot-daemon ed esci da ot-ctl, quindi riavviali all'interno di nuove finestre di Screen (Ctrl+a → c).

Questa configurazione non è obbligatoria e viene lasciata come esercizio per l'utente.

Dividi e sposta le finestre con i seguenti comandi:

Crea nuova finestra	Ctrl+a → c
Dividere la finestra in verticale	Ctrl+A →
Dividere la finestra in orizzontale	Ctrl+a → S
Passa alla finestra visualizzata successiva	Ctrl+a → Tab
Passare alla finestra visualizzata successiva o precedente	Ctrl+a → n o p
Rinomina la finestra corrente	Ctrl+a → A

Esci da Screen in qualsiasi momento con Ctrl+a → d e ricollegati con screen -r dalla riga di comando.

Nota: se ti scolleghi dalla sessione di Screen, la configurazione della finestra divisa non viene salvata.

Per ulteriori informazioni su Screen, consulta la guida di riferimento rapido di GNU Screen.

7. Crea la rete Thread

Importante:le informazioni identificative sui nodi Thread, come indirizzi IPv6, RLOC16 e indirizzi MAC, saranno diverse da quelle nell'output di esempio di questo codelab.

Ora che hai configurato tutte le finestre e le schermate del terminale, creiamo la nostra rete Thread. In FTD Commissioner, crea un nuovo set di dati operativi e eseguine il commit come attivo. Il set di dati operativo è la configurazione della rete Thread che stai creando.

dataset init new crea un nuovo set di dati operativi con valori casuali. I tuoi valori saranno diversi da quelli mostrati in questo Codelab. Sostituisci i valori nei comandi di esempio di Codelab con i valori del tuo Operational Dataset.

## FTD Commissioner ##
----------------------

> dataset init new
Done
> dataset
Active Timestamp: 1
Channel: 11
Channel Mask: 07fff800
Ext PAN ID: c0de7ab5c0de7ab5
Mesh Local Prefix: fdc0:de7a:b5c0/64
Network Key: 1234c0de7ab51234c0de7ab51234c0de
Network Name: OpenThread-c0de
PAN ID: 0xc0de
PSKc: ebb4f2f8a68026fc55bcf3d7be3e6fe4
Security Policy: 0, onrcb
Done

Prendi nota della chiave di rete 1234c0de7ab51234c0de7ab51234c0de, che verrà utilizzata in un secondo momento.

Esegui il commit di questo set di dati come quello attivo:

> dataset commit active
Done

Visualizza l'interfaccia IPv6:

> ifconfig up
Done

Avvia l'operazione del protocollo Thread:

> thread start
Done

Dopo qualche istante, controlla lo stato del dispositivo. Dovrebbe essere il leader. Prendi nota anche del RLOC16 per riferimento futuro.

## FTD Commissioner ##
----------------------

> state
leader
Done
> rloc16
0c00
Done

Controlla gli indirizzi IPv6 del dispositivo:

## FTD Commissioner ##
----------------------

> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:fc00        # Leader Anycast Locator (ALOC)
fdc0:de7a:b5c0:0:0:ff:fe00:c00         # Routing Locator (RLOC)
fdc0:de7a:b5c0:0:6394:5a75:a1ad:e5a    # Mesh-Local EID (ML-EID)
fe80:0:0:0:1cd6:87a9:cb9d:4b1d         # Link-Local Address (LLA)

Un singolo nodo Thread ha più indirizzi IPv6. Per saperne di più, consulta Indirizzamento IPv6.

La rete "codelab" ora è visibile quando viene scansionata da altri dispositivi Thread.

A partire dal giorno ot-ctl sul RCP Joiner:

## RCP Joiner ##
----------------

> scan
| PAN  | MAC Address      | Ch | dBm | LQI |
+------+------------------+----+-----+-----+
| c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |

Dall'interfaccia a riga di comando OpenThread sul FTD Joiner:

## FTD Joiner ##
----------------

> scan
| PAN  | MAC Address      | Ch | dBm | LQI |
+------+------------------+----+-----+-----+
| c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |

Se la rete "codelab" non viene visualizzata nell'elenco, prova a eseguire di nuovo la scansione.

8. Aggiungere lo strumento di unione RCP

Il provisioning di Thread non è attivo sulla rete, il che significa che dovremo aggiungere RCP Joiner alla rete Thread che abbiamo appena creato utilizzando una procedura di provisioning out-of-band.

Il provisioning in banda si verifica quando le credenziali di rete vengono trasferite al dispositivo che si connette via radio. Il provisioning out-of-band si verifica quando le credenziali vengono fornite al dispositivo di unione con altri mezzi (ad esempio, l'inserimento manuale nell'interfaccia a riga di comando OpenThread).

In FTD Commissioner, abbiamo annotato la chiave di rete, ad esempio 1234c0de7ab51234c0de7ab51234c0de. Se devi cercare di nuovo la chiave di rete, esegui questo comando sul FTD Commissioner:

## FTD Commissioner ##

> dataset networkkey
1234c0de7ab51234c0de7ab51234c0de
Done

Successivamente, in RCP Joiner, imposta la chiave di rete del set di dati attivo sulla chiave di rete del commissario FTD:

## RCP Joiner ##
----------------

> dataset networkkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

Controlla il set di dati per assicurarti che sia impostato correttamente.

## RCP Joiner ##
----------------

> dataset
Network Key: 1234c0de7ab51234c0de7ab51234c0de

Visualizza Thread in modo che RCP Joiner si unisca alla rete "codelab". Attendi qualche secondo, controlla lo stato, RLOC16 e i relativi indirizzi IPv6:

## RCP Joiner ##
----------------

> ifconfig up
Done
> thread start
Done
> state
child
Done
> rloc16
0c01
Done
> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:0c01         # Routing Locator (RLOC)
fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f    # Mesh-Local EID (ML-EID)
fe80:0:0:0:18e5:29b3:a638:943b          # Link-Local Address (LLA)
Done

Prendi nota dell'indirizzo IPv6 locale della mesh (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f), lo utilizzerai in un secondo momento.

Tornato su FTD Commissioner, controlla le tabelle del router e dei dispositivi secondari per verificare che entrambi i dispositivi facciano parte della stessa rete. Utilizza RLOC16 per identificare RCP Joiner.

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  35 | 1ed687a9cb9d4b1d |

Done
> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|VER| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+---+------------------+
|   1 | 0x0c01 |        240 |         25 |     3 |   89 |1|1|1|  2| 1ae529b3a638943b |
Done

Invia un ping all'indirizzo mesh-local del RCP Joiner (l'indirizzo mesh-local ottenuto dall'output ipaddr di RCP Joiner) per verificare la connettività:

## FTD Commissioner ##
----------------------

> ping fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f
> 8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=1 hlim=64 time=40ms

Ora abbiamo una rete Thread composta da due nodi, illustrata in questo diagramma di topologia:

Diagrammi di topologia

Man mano che procedi con il resto del codelab, mostreremo un nuovo diagramma della topologia di Thread ogni volta che lo stato della rete cambia. I ruoli dei nodi sono indicati come segue:

I router sono sempre pentagoni e i dispositivi finali sono sempre cerchi. I numeri su ogni nodo rappresentano l'ID router o l'ID figlio mostrato nell'output della CLI, a seconda del ruolo e dello stato attuali di ogni nodo in quel momento.

9. Commissionare FTD Joiner

Ora aggiungiamo il terzo dispositivo Thread alla rete "codelab". Questa volta utilizzeremo la procedura di provisioning in banda più sicura e consentiremo l'accesso solo al nodo di giunzione FTD.

Nell'FTD Joiner, recupera eui64 in modo che il commissario FTD possa identificarlo:

## FTD Joiner ##
----------------

> eui64
2f57d222545271f1
Done

Su FTD Commissioner, avvia il commissario e specifica il eui64 del dispositivo che può partecipare, insieme alle credenziali di Joiner, ad esempio J01NME. La credenziale di accoppiamento è una stringa specifica del dispositivo composta da caratteri alfanumerici maiuscoli (0-9 e A-Y, escluse I, O, Q e Z per leggibilità), con una lunghezza compresa tra 6 e 32 caratteri.

## FTD Commissioner ##
----------------------

> commissioner start
Done
> commissioner joiner add 2f57d222545271f1 J01NME
Done

Avviso:se ricevi un errore durante l'esecuzione del comando commissioner joiner, interrompi e riavvia il ruolo di commissario con commissioner stop e commissioner start, quindi riprova il comando commissioner joiner.

Passa a FTD Joiner. Avvia il ruolo di joiner con la credenziale di joiner che hai appena configurato sul commissario FTD:

## FTD Joiner ##
----------------

> ifconfig up
Done
> joiner start J01NME
Done

Entro un minuto circa, ricevi la conferma dell'autenticazione riuscita:

## FTD Joiner ##
----------------

>
Join success

Avviso:se aspetti troppo a lungo (più di qualche minuto) per iniziare il ruolo di installatore sul FTD Joiner, il commissario potrebbe andare in timeout e l'unione non riuscirà. Interrompi e riavvia il commissario e riprova.

Visualizza Thread in modo che FTD Joiner si connetta alla rete "codelab" e controlla immediatamente lo stato e RLOC16:

## FTD Joiner ##
----------------

> thread start
Done
> state
child
Done
> rloc16
0c02
Done

Controlla gli indirizzi IPv6 del dispositivo. Nota che non è presente alcun ALOC. Questo perché il dispositivo non è il Leader e non ha un ruolo specifico per Anycast che richiede un ALOC.

## FTD Joiner ##
----------------

> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:c02         # Routing Locator (RLOC)
fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd    # Mesh-Local EID (ML-EID)
fe80:0:0:0:e4cd:d2d9:3249:a243         # Link-Local Address (LLA)

Passa immediatamente a FTD Commissioner e controlla le tabelle del router e dei dispositivi secondari per verificare che esistano tre dispositivi nella rete "codelab":

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  50 | 1ed687a9cb9d4b1d |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0x0c01 |        240 |         25 |     3 |   89 |1|1|1|1| 1ae529b3a638943b |
|   2 | 0x0c02 |        240 |         15 |     3 |   44 |1|1|1|1| e6cdd2d93249a243 |
Done

Importante:è possibile che quando controlli le tabelle del router e del dispositivo secondario, visualizzi due router e un dispositivo finale (secondario). In questo caso, non preoccuparti. Non hai fatto nulla di male. Continua a leggere per scoprire perché è successo.

In base a RLOC16, il dispositivo FTD Joiner si è connesso alla rete come dispositivo finale (secondario). Ecco la nostra topologia aggiornata:

10. Thread in azione

I dispositivi Thread in questo Codelab sono un tipo specifico di dispositivo Thread completo (FTD) chiamato Router Eligible End Device (REED). Ciò significa che possono funzionare come router o dispositivo finale e possono passare da dispositivo finale a router.

Thread può supportare fino a 32 router, ma cerca di mantenere il numero di router tra 16 e 23. Se un REED si collega come dispositivo finale (secondario) e il numero di router è inferiore a 16, dopo un periodo di tempo casuale entro due minuti viene promosso automaticamente a router.

Se avevi due dispositivi secondari nella tua rete Thread dopo aver aggiunto FTD Joiner, attendi almeno due minuti, quindi controlla di nuovo le tabelle del router e dei dispositivi secondari in FTD Commissioner:

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  50 | 1ed687a9cb9d4b1d |
| 46 | 0xb800 |       63 |         0 |     3 |      3 |   1 | e6cdd2d93249a243 |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0x0c01 |        240 |         61 |     3 |   89 |1|1|1|1| 1ae529b3a638943b |
Done

FTD Joiner (Extended MAC = e6cdd2d93249a243) è stato promosso a router. Tieni presente che l'RLOC16 è diverso (b800 anziché 0c02). Questo perché l'RLOC16 si basa sull'ID router e sull'ID bambino di un dispositivo. Quando passa da dispositivo finale a router, i valori di ID router e ID secondario cambiano, così come RLOC16.

Conferma il nuovo stato e RLOC16 in FTD Joiner:

## FTD Joiner ##
----------------

> state
router
Done
> rloc16
b800
Done

Eseguire il downgrade di FTD Joiner

Puoi testare questo comportamento eseguendo manualmente il downgrade del FTD Joiner da un router a un dispositivo finale. Modifica lo stato in secondario e controlla RLOC16:

## FTD Joiner ##
----------------

> state child
Done
> rloc16
0c03
Done

Tornando a FTD Commissioner, ora FTD Joiner dovrebbe essere visualizzato nella tabella secondaria (ID = 3). Potrebbe anche essere presente in entrambe durante la transizione:

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  50 | 1ed687a9cb9d4b1d |
| 46 | 0xb800 |       63 |         0 |     3 |      3 |   1 | e6cdd2d93249a243 |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0x0c01 |        240 |         61 |     3 |   89 |1|1|1|1| 1ae529b3a638943b |
|   3 | 0x0c03 |        240 |         16 |     3 |   94 |1|1|1|1| e6cdd2d93249a243 |
Done

Dopo un po' di tempo, tornerà a un router con un RLOC di b800.

Rimuovere il leader

Il leader viene eletto autonomamente tra tutti i router Thread. Ciò significa che se il leader attuale viene rimosso dalla rete Thread, uno degli altri router diventerà il nuovo leader.

Sul FTD Commissioner, disattiva Thread per rimuoverlo dalla rete Thread:

## FTD Commissioner ##
----------------------

> thread stop
Done
> ifconfig down
Done

Entro due minuti, il FTD Joiner diventa il nuovo leader del thread. Controlla lo stato e gli indirizzi IPv6 di FTD Joiner per verificare:

## FTD Joiner ##
----------------

> state
leader
Done
> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:fc00       # Now it has the Leader ALOC!
fdc0:de7a:b5c0:0:0:ff:fe00:b800
fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd
fe80:0:0:0:e4cd:d2d9:3249:a243
Done

Controlla la tabella figlio. Tieni presente che è presente un nuovo RLOC16. Si tratta del RCP Joiner, come indicato dal relativo ID e dall'indirizzo MAC esteso. Per mantenere unita la rete Thread, ha cambiato i router principali, passando dal FTD Commissioner al FTD Joiner. Il risultato è un nuovo RLOC16 per RCP Joiner (perché il suo ID router è cambiato, da 3 a 46).

## FTD Joiner ##
----------------

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0xb801 |        240 |         27 |     3 |  145 |1|1|1|1| 1ae529b3a638943b |
Done

Potresti dover attendere alcuni minuti prima che RCP Joiner venga collegato a FTD Joiner come elemento secondario. Controlla lo stato e RLOC16 per verificare che:

## RCP Joiner ##
--------------

> state
child
> rloc16
b801

Ricollega il commissario FTD

Una rete Thread con due nodi non è molto divertente. Riportiamo online il commissario dell'FTD.

In FTD Commissioner, riavvia Thread:

## FTD Commissioner ##
----------------------

> ifconfig up
Done
> thread start
Done

Entro due minuti, si ricollega automaticamente alla rete "codelab" come dispositivo finale e poi si promuove a router.

## FTD Commissioner ##
----------------------

> state
router
Done

Controlla le tabelle del router e secondarie in FTD Joiner per verificare:

## FTD Joiner ##
----------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |       63 |         0 |     3 |      3 |   0 | 1ed687a9cb9d4b1d |
| 46 | 0xb800 |       46 |         0 |     0 |      0 |  15 | e6cdd2d93249a243 |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0xb801 |        240 |        184 |     3 |  145 |1|1|1|1| 1ae529b3a638943b |
Done

La nostra rete Thread è di nuovo composta da tre nodi.

"Entro due minuti…"

Potresti aver notato questo aspetto più volte nel Codelab, quando si attende che un dispositivo cambi stato. 120 secondi è il valore predefinito di un parametro della rete Thread chiamato ROUTER_SELECTION_JITTER. I dispositivi che passano da dispositivo finale a router o viceversa ritardano la modifica per un periodo casuale compreso tra 0 e ROUTER_SELECTION_JITTER (in secondi). Per ulteriori informazioni sui parametri della rete Thread, consulta la specifica Thread.

11. Risoluzione dei problemi

Gestire una rete Thread con più dispositivi in finestre diverse del terminale o dello schermo può essere complicato. Utilizza questi suggerimenti per "reimpostare" lo stato della rete o dello spazio di lavoro se riscontri problemi.

Schermo

Se ti perdi nella configurazione (troppe finestre di Screen o Screen all'interno di Screen), continua a chiudere le finestre di Screen con Ctrl+a → k finché non ne rimangono più e screen -ls nella riga di comando restituisce No Sockets found. Poi ricrea le finestre dello schermo per ogni dispositivo. Gli stati del dispositivo vengono mantenuti anche quando lo schermo viene chiuso.

Nodi Thread

Se la topologia della rete Thread non è quella descritta in questo Codelab o se i nodi si disconnettono per qualche motivo (ad esempio perché la macchina Linux che li alimenta è in modalità sospensione), è consigliabile disattivare Thread, cancellare le credenziali di rete e ricominciare dal passaggio Crea la rete Thread.

Per reimpostare i FTD:

## FTD Commissioner or FTD Joiner ##
------------------------------------

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

Il RCP può essere reimpostato allo stesso modo tramite ot-ctl:

## RCP Joiner ##
----------------

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

12. Utilizzo del multicast

Il multicast viene utilizzato per comunicare informazioni a un gruppo di dispositivi contemporaneamente. In una rete Thread, indirizzi specifici sono riservati all'utilizzo multicast con diversi gruppi di dispositivi, a seconda dell'ambito.

Indirizzo IPv6	Ambito	Consegnato a
ff02::1	Link-Local	Tutti i FTD e i MED
ff02::2	Link-Local	Tutti i FTD e i router di confine
ff03::1	Mesh-Local	Tutti i FTD e i MED
ff03::2	Mesh-Local	Tutti i FTD e i router di confine

Poiché in questo Codelab non utilizziamo un router di confine, concentriamoci sui due indirizzi multicast FTD e MED.

Link-Local

L'ambito Link-Local comprende tutte le interfacce Thread raggiungibili con una singola trasmissione radio o un singolo "hop". La topologia di rete determina quali dispositivi rispondono a un ping all'indirizzo multicast ff02::1.

Ping ff02::1 del FTD Commissioner:

## FTD Commissioner ##
----------------------

> ping ff02::1
> 8 bytes from fe80:0:0:0:e4cd:d2d9:3249:a243: icmp_seq=2 hlim=64 time=9ms

Nella rete sono presenti altri due dispositivi (FTD Joiner e RCP Joiner), ma FTD Commissioner ha ricevuto una sola risposta, dall'indirizzo Link-Local (LLA) di FTD Joiner. Ciò significa che FTD Joiner è l'unico dispositivo che FTD Commissioner può raggiungere con un singolo hop.

Ora esegui il ping di ff02::1 da FTD Joiner:

## FTD Joiner ##
----------------

> ping ff02::1
> 8 bytes from fe80:0:0:0:1cd6:87a9:cb9d:4b1d: icmp_seq=1 hlim=64 time=11ms
8 bytes from fe80:0:0:0:18e5:29b3:a638:943b: icmp_seq=1 hlim=64 time=24ms

Due risposte! Controllando gli indirizzi IPv6 degli altri dispositivi, possiamo vedere che il primo (che termina con 4b1d) è l'LLA del commissario FTD, mentre il secondo (che termina con 943b) è l'LLA del richiedente RCP.

Ciò significa che FTD Joiner è collegato direttamente sia a FTD Commissioner sia a RCP Joiner, il che conferma la nostra topologia.

Mesh-Local

L'ambito Mesh-Local comprende tutte le interfacce Thread raggiungibili all'interno della stessa rete Thread. Vediamo le risposte a un ping all'indirizzo multicast ff03::1.

Ping ff03::1 del FTD Commissioner:

## FTD Commissioner ##
----------------------

> ping ff03::1
> 8 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:b800: icmp_seq=3 hlim=64 time=9ms
8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=3 hlim=64 time=68ms

Questa volta il commissario FTD ha ricevuto due risposte, una dal localizzatore di routing (RLOC, che termina con b800) del joiner FTD e una dall'EID locale della mesh (ML-EID, che termina con d55f) del joiner RCP. Questo perché l'ambito locale della mesh comprende l'intera rete Thread. Indipendentemente dalla posizione di un dispositivo nella rete, questo sarà iscritto all'indirizzo ff03::1.

Invia un ping a ff03::1 da FTD Joiner per confermare lo stesso comportamento:

## FTD Joiner ##
----------------

> ping ff03::1
> 8 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00: icmp_seq=2 hlim=64 time=11ms
8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=2 hlim=64 time=23ms

Prendi nota del tempo di risposta per RCP Joiner in entrambi gli output ping. Il componente di unione RCP ha impiegato molto più tempo per raggiungere il componente di unione FTD (68 ms) rispetto al componente di unione FTD (23 ms). Questo perché deve fare due hop per raggiungere il commissario FTD, rispetto a un hop per il partecipante FTD.

Potresti anche aver notato che il ping multicast locale della mesh ha risposto con l'RLOC solo per i due FTD, non per l'RCP Joiner. Questo perché gli FTD sono router all'interno della rete, mentre l'RCP è un dispositivo finale.

Controlla lo stato di RCP Joiner per confermare:

## RCP Joiner ##
----------------

> state
child

13. Inviare messaggi con UDP

Uno dei servizi applicativi forniti da OpenThread è User Datagram Protocol (UDP), un protocollo del livello di trasporto. Un'applicazione basata su OpenThread potrebbe utilizzare l'API UDP per passare messaggi tra i nodi di una rete Thread o ad altri dispositivi in una rete esterna (come internet, se la rete Thread dispone di un router di confine).

I socket UDP sono esposti tramite la CLI OpenThread. Usiamolo per scambiare messaggi tra i due FTD.

Ottieni l'indirizzo EID locale della mesh per il FTD Joiner. Utilizziamo questo indirizzo perché è raggiungibile da qualsiasi punto della rete Thread.

## FTD Joiner ##
----------------

> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:fc00        # Leader Anycast Locator (ALOC)
fdc0:de7a:b5c0:0:0:ff:fe00:b800        # Routing Locator (RLOC)
fe80:0:0:0:e4cd:d2d9:3249:a243         # Link-Local Address (LLA)
fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd    # Mesh-Local EID (ML-EID)
Done

Avvia UDP e associalo a un socket per qualsiasi indirizzo IPv6:

## FTD Joiner ##
----------------

> udp open
Done
> udp bind :: 1212

Passa a FTD Commissioner, avvia UDP e connettiti al socket che hai configurato in FTD Joiner utilizzando il relativo ML-EID:

## FTD Commissioner ##
----------------------

> udp open
Done
> udp connect fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd 1212
Done

La connessione UDP deve essere attiva tra i due nodi. Invia un messaggio dal commissario dell'FTD:

## FTD Commissioner ##
----------------------

> udp send hellothere
Done

In FTD Joiner, il messaggio UDP è stato ricevuto.

## FTD Joiner ##
----------------

> 10 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00 49153 hellothere

14. Complimenti!

Hai creato una rete Thread fisica.

Ora sai che:

• la differenza tra tipi, ruoli e ambiti dei dispositivi Thread
• come i dispositivi Thread gestiscono i loro stati all'interno della rete
• come passare messaggi semplici tra i nodi utilizzando UDP

Passaggi successivi

Partendo da questo codelab, prova i seguenti esercizi:

• Ricarica la scheda FTD Joiner come MTD utilizzando il binario ot-cli-mtd e osserva che non esegue mai l'upgrade a un router o non tenta di diventare il leader
• Aggiungi altri dispositivi (prova una piattaforma diversa) alla rete e abbozza la topologia utilizzando le tabelle del router e dei dispositivi secondari, insieme ai ping agli indirizzi multicast.
• Utilizza pyspinel per controllare l'NCP
• Converti l'NCP in un router di confine utilizzando OpenThread Border Router e connetti la tua rete Thread a internet

Per approfondire

Visita openthread.io e GitHub per trovare una serie di risorse OpenThread, tra cui:

• Piattaforme supportate: scopri tutte le piattaforme che supportano OpenThread
• Build OpenThread: ulteriori dettagli sulla creazione e la configurazione di OpenThread
• Thread Primer: copre tutti i concetti di Thread trattati in questo codelab

Riferimento:

• Riferimento per l'interfaccia a riga di comando OpenThread
• Riferimento alla CLI UDP di OpenThread
• Riferimento al daemon OpenThread
• Riferimento API UDP OpenThread
• Riferimento rapido di GNU Screen