Costruisci una rete di thread con schede nRF52840 e OpenThread

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 per accelerare lo sviluppo di prodotti per la casa connessa.

La specifica Thread definisce un protocollo di comunicazione da dispositivo a dispositivo wireless affidabile, sicuro ea basso consumo basato su IPv6 per 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 passerai messaggi tra i nodi.

Cosa imparerai

Creazione e aggiornamento dei binari della CLI OpenThread nelle schede di sviluppo
Costruire un RCP composto da una macchina Linux e una scheda di sviluppo
Comunicazione con un RCP utilizzando OpenThread Daemon e ot-ctl
Gestione manuale dei nodi di thread con Screen e OpenThread CLI
Messa in servizio sicura dei dispositivi su una rete Thread
Come funziona il multicast IPv6
Passaggio di messaggi tra i nodi Thread con UDP

Di cosa avrai bisogno

Hardware:

3 schede di sviluppo Nordic Semiconductor nRF52840
3 cavi da USB a Micro-USB per collegare le schede
Una macchina Linux con almeno 3 porte USB

Software:

GNU Toolchain
Strumenti da riga di comando Nordic nRF5x
Software Segger J-Link
OpenThread
Idiota

Salvo quanto diversamente indicato, il contenuto di questo Codelab è concesso in licenza con la licenza Creative Commons Attribution 3.0 e gli esempi di codice sono concessi in licenza con la licenza Apache 2.0 .

OpenThread Simulation

Prima di iniziare, potresti voler eseguire il codelab di simulazione OpenThread , per acquisire familiarità con i concetti di base di Thread e OpenThread CLI.

Terminali per porta seriale

Dovresti avere familiarità con come connetterti a una porta seriale tramite un terminale. Questo Codelab utilizza Screen e fornisce una panoramica sull'utilizzo, ma è possibile utilizzare qualsiasi altro software del terminale.

Macchina Linux

Questo Codelab è stato progettato per utilizzare una macchina Linux basata su i386 o x86 per fungere da host per un dispositivo Thread Radio Co-Processor (RCP) e per aggiornare 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 PDK nRF52840 .

Installa SEGGER J-Link

Usiamo SEGGER J-Link per programmare le schede nRF52840, che hanno moduli JTAG integrati. Installalo sulla tua macchina Linux.

Scarica il software J-Link e il pacchetto di documentazione

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

Installa nRF5x Command Line Tools

Gli strumenti della riga di comando nRF5x consentono di eseguire il flashing dei binari di OpenThread sulle schede nRF52840. Installa la build nRF5x-Command-Line-Tools- <OS> appropriata sulla tua macchina Linux.

Scarica nRF5x Command Line Tools

Posiziona il pacchetto estratto nella cartella principale ~/

Installa ARM GNU Toolchain

La Toolchain GNU ARM viene utilizzata per la creazione di file.

Scarica l'archivio portatile ARM GNU Toolchain

Ti consigliamo di posizionare l'archivio estratto in /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/ sulla tua macchina Linux. Seguire le istruzioni nel file readme.txt dell'archivio per le istruzioni di installazione.

Schermata di installazione (opzionale)

Screen è un semplice strumento per accedere ai dispositivi collegati da una porta seriale. Questo Codelab usa Screen, ma puoi usare qualsiasi applicazione terminale per porta seriale che desideri.

$ sudo apt-get install screen

OpenThread

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

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

Costruisci il demone OpenThread:

$ script/cmake-build posix -DOT_DAEMON=ON

Ora sei pronto per creare e aggiornare OpenThread sulle schede nRF52840.

Costruisci e fai il flash

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

Pulisci sempre prima il repository delle build precedenti eseguendo make clean .

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

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

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

Collegare il cavo USB alla porta di debug Micro-USB accanto al pin di alimentazione esterna sulla scheda nRF52840, quindi collegarlo alla macchina Linux. Impostare l'interruttore della sorgente di alimentazione nRF sulla scheda nRF52840 su VDD . Quando è collegato correttamente, il LED5 è acceso.

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

$ ls /dev/ttyACM*
/dev/ttyACM0

Annotare il numero di serie della scheda nRF52840 utilizzata per l'RCP:

Passare alla posizione degli strumenti della riga di comando nRFx e lampeggiare il file esadecimale OpenThread RCP sulla scheda nRF52840, utilizzando il numero di serie della scheda:

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

Il seguente output viene generato in caso di successo:

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 seguito.

Connetti a USB nativo

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

Scollegare l'estremità Micro-USB del cavo USB dalla porta di debug della scheda nRF52840 lampeggiante, quindi ricollegarla alla porta Micro-USB nRF USB accanto al pulsante RESET . Impostare l'interruttore della sorgente di alimentazione nRF su USB .

Avvia OpenThread Daemon

Nella progettazione RCP, utilizzare OpenThread Daemon per comunicare e gestire il dispositivo Thread. Avvia ot-daemon con il flag -v verbose in modo da poter vedere l'output del log e confermare che sia in esecuzione:

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

Quando ha successo, ot-daemon in modalità dettagliata genera un output simile al seguente:

ot-daemon[228024]: Running OPENTHREAD/20191113-00831-gfb399104; POSIX; Jun  7 2020 18:05:15
ot-daemon[228024]: Thread version: 2
ot-daemon[228024]: RCP version: OPENTHREAD/20191113-00831-gfb399104; SIMULATION; Jun  7 2020 18:06:08

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

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

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

$ ./output/posix/bin/ot-ctl
>

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

> state
disabled
Done

Gli altri due nodi Thread utilizzati in questo Codelab sono FTD (Full Thread Devices) sul design System-on-Chip (SoC) standard. Non usano wpantund e l'utente li gestisce manualmente con OpenThread CLI.

Un dispositivo funziona come Commissioner, per autenticare e mettere in servizio in modo sicuro i dispositivi su quella rete. L'altro dispositivo funziona come un Joiner che il Commissioner può autenticare sulla rete Thread.

Costruisci e fai il flash

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

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

Passa 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

Collegare il cavo USB alla porta Micro-USB accanto al pin di alimentazione esterna sulla scheda nRF52840, quindi collegarlo alla macchina Linux. Se l'RCP è ancora collegato alla macchina Linux, questa nuova scheda dovrebbe apparire come porta seriale /dev/ttyACM1 (tutte le schede ttyACM usano ttyACM per l'identificativo della porta seriale).

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

Come prima, annotare il numero di serie della scheda nRF52840 utilizzata per l'FTD:

Passare alla posizione degli strumenti della riga di comando nRFx e lampeggiare il file esadecimale OpenThread CLI FTD sulla scheda nRF52840, utilizzando il numero di serie della scheda:

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

Etichetta la scheda "Commissario".

Verifica build

Verifica una build di successo accedendo alla CLI di OpenThread utilizzando GNU Screen da una finestra di terminale. Le schede nRF52840 utilizzano una velocità di trasmissione di 115200.

$ screen /dev/ttyACM1 115200

Nella nuova finestra, premi Invio sulla tastiera alcune volte per visualizzare il prompt OpenThread CLI > . Apri 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 scollegarsi dalla schermata della CLI di FTD Commissioner e tornare al terminale Linux in modo da poter eseguire il flashing della scheda successiva. Per accedere nuovamente alla CLI in qualsiasi momento, utilizzare screen -r dalla riga di comando. Per vedere un elenco delle schermate disponibili, usa screen -ls :

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

Configurare FTD Joiner

Ripeti il processo precedente per eseguire il flashing della terza scheda nRF52840, utilizzando la build ot-cli-ftd.hex .

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

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

Etichetta la scheda "Falegname".

Durante la verifica utilizzando Screen, invece di creare una nuova istanza di Screen dalla riga di comando, ricollegati a quella esistente e crea una nuova finestra al suo interno (che hai usato per il Commissario FTD):

$ screen -r

Crea la nuova finestra all'interno dello schermo con Ctrl + a →

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

$ screen /dev/ttyACM2 115200

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

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

Ora che la CLI di FTD Joiner è nella stessa istanza di Screen del Commissario FTD, puoi passare da una all'altra usando Ctrl + a → n .

Usa Ctrl + a →

d in qualsiasi momento per uscire dalla schermata.

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

Idealmente, dovresti avere quattro finestre prontamente disponibili:

servizio / log ot-daemon
RCP Joiner tramite ot-ctl
Commissario FTD tramite OpenThread CLI
FTD Joiner tramite OpenThread CLI

Se desideri utilizzare la tua configurazione o strumento di terminale / porta seriale, non esitare a passare al passaggio successivo. Configura le finestre del terminale per tutti i dispositivi nel modo che funziona meglio per te.

Utilizzo dello schermo

Per facilità d'uso, avvia solo una sessione dello schermo. Dovresti già averne uno da quando hai impostato entrambi gli FTD.

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

Comandi di base dello schermo:

Ricollegarsi alla sessione dello schermo (dalla riga di comando)	`screen -r`
Esci dalla sessione Screen	Ctrl + a → `d`
Crea una nuova finestra nella sessione Screen	Ctrl + a → `c`
Passa da una finestra all'altra nella stessa sessione dello schermo	Ctrl + a → `n` (avanti) Ctrl + a → `p` (indietro)
Elimina la finestra corrente nella sessione Screen	Ctrl + a → `k`

Schermo diviso

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

Si accede ai comandi screen usando Ctrl + a. Ogni comando dovrebbe iniziare con questa combinazione di tasti di accesso.

Se hai seguito esattamente il Codelab, dovresti avere due finestre (FTD Commissioner, FTD Joiner) sulla stessa istanza di Screen. Per dividere lo schermo tra i due, prima accedi alla tua sessione Screen esistente:

$ screen -r

Dovresti essere su uno dei dispositivi FTD. Segui questi passaggi nello schermo:

Ctrl + a → S per dividere la finestra orizzontalmente
Ctrl + a → Tab per spostare il cursore sulla nuova finestra vuota
Ctrl + a → n per passare dalla nuova finestra a quella successiva
Se è uguale alla finestra in alto, Ctrl + a → n nuovo per visualizzare l'altro dispositivo FTD

Ora sono entrambi visibili. Passa da uno all'altro usando Ctrl + a → Tab . Si consiglia di rinominare ogni finestra con Ctrl + a → A per evitare confusione.

Uso avanzato

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

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

Dividi e naviga tra le finestre con i seguenti comandi:

Crea nuova finestra	Ctrl + a → `c`
Finestra divisa verticalmente	Ctrl + a →
Finestra divisa orizzontalmente	Ctrl + a → `S`
Passa alla successiva finestra visualizzata	Ctrl + a → `Tab`
Cambia la finestra visualizzata in avanti o indietro	Ctrl + a → `n` `p`
Rinomina la finestra corrente	Ctrl + a → `A`

Lasciare dello schermo in qualsiasi momento con Ctrl + A → d e riattaccare con screen -r dalla riga di comando.

Per ulteriori informazioni su Screen, vedere la Guida rapida allo schermo GNU .

Ora che hai configurato tutte le finestre e gli schermi del tuo terminale, creiamo la nostra rete di thread. Sul Commissario FTD , crea un nuovo set di dati operativo e impegnalo come quello attivo. Il set di dati operativi è la configurazione per la rete di thread che stai creando.

## 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
Master Key: 1234c0de7ab51234c0de7ab51234c0de
Network Name: OpenThread-c0de
PAN ID: 0xc0de
PSKc: ebb4f2f8a68026fc55bcf3d7be3e6fe4
Security Policy: 0, onrcb
Done

Prendere nota della chiave principale 1234c0de7ab51234c0de7ab51234c0de che verrà utilizzata in seguito.

Salva 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 un momento, controlla lo stato del dispositivo. Dovrebbe essere il leader. Ottieni anche 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)

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

Da ot-ctl su RCP Joiner :

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

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |

Dalla CLI di OpenThread su FTD Joiner :

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

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |

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

È possibile notare che in entrambe le scansioni la rete sembra non essere unibile (colonna J su RCP Joiner e FTD Joiner). Ciò significa solo che Thread Commissioning non è attivo sulla rete. Può ancora essere unito fuori banda, inserendo manualmente la chiave principale di rete nel dispositivo di unione.

Aggiungiamo RCP Joiner alla rete Thread che abbiamo appena creato, utilizzando un processo fuori banda. Cerca reti su RCP Joiner :

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

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |

Per aderire, impostare la chiave principale di rete (che abbiamo appena ottenuto dal commissario FTD) su RCP Joiner nel suo dataset attivo.

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

> dataset masterkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

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

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

> dataset
Master Key: 1234c0de7ab51234c0de7ab51234c0de

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

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

> 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 Mesh-Local ( fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f qui), lo utilizzerai in seguito.

Torna su FTD Commissioner , controlla il router e le tabelle secondarie per confermare che entrambi i dispositivi fanno parte della stessa rete. Utilizzare 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

Eseguire il ping dell'indirizzo mesh locale di RCP Joiner (l'indirizzo Mesh-Local ottenuto dall'output ipaddr 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 di thread composta da due nodi, illustrata da questo diagramma della topologia:

Diagrammi topologici

Man mano che si lavora nel resto del Codelab, verrà mostrato un nuovo diagramma della topologia del 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 ciascun nodo rappresentano l'ID router o l'ID figlio mostrato nell'output della CLI, a seconda del ruolo e dello stato corrente di ciascun nodo in quel momento.

Ora aggiungiamo il terzo dispositivo Thread alla rete "codelab". Questa volta utilizzeremo il più sicuro processo di messa in servizio in banda. Su FTD Joiner , cerca la rete:

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

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | f65ae2853ff0c4e4 | 11 | -36 |  57 |

Uno 0 nella colonna J indica che la messa in servizio del thread non è attiva sul dispositivo.

Cerchiamo di essere precisi durante la messa in servizio su questo prossimo dispositivo e di consentire solo a FTD Joiner di unirsi. Sempre su FTD Joiner, eui64 l' eui64 , in modo che il Commissario FTD possa identificarlo:

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

> eui64
2f57d222545271f1
Done

Sul Commissario FTD , avvia il Commissario e specifica l' eui64 del dispositivo che può aderire, insieme alle Credenziali di Joiner. La credenziale Joiner è una passphrase specifica del dispositivo.

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

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

Passare a FTD Joiner e ripetere la scansione:

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

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 1 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -45 | 196 |

Come indicato 1 nella colonna J, il Thread Commissioning è ora attivo sulla rete. Inizia il ruolo di falegname con le credenziali di falegname che hai appena impostato sul Commissario FTD:

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

> ifconfig up
Done
> joiner start J01NME
Done

Entro un minuto circa, ricevi una conferma di un'autenticazione riuscita:

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

>
Join success

Apri Thread in modo che FTD Joiner si unisca 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. Si noti che non è presente alcun ALOC. Questo perché questo dispositivo non è il leader, né ha un ruolo specifico di 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 al Commissario FTD e controlla il router e le tabelle secondarie per confermare che nella rete "codelab" esistono tre dispositivi:

## 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

Basato su RLOC16, FTD Joiner si è collegato alla rete come un dispositivo finale (figlio). Ecco la nostra topologia aggiornata:

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

Il 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 (figlio) e il numero di router è inferiore a 16, dopo un periodo di tempo casuale entro due minuti si promuove automaticamente a un router.

Se hai due figli nella tua rete Thread dopo aver aggiunto FTD Joiner, attendi almeno due minuti, quindi ricontrolla il router e le tabelle figlio sul Commissario FTD :

## 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 ) si è promosso a un router. Notare che RLOC16 è diverso ( b800 invece di 0c02 ). Questo perché RLOC16 si basa sull'ID router e sull'ID figlio di un dispositivo. Quando passa dal dispositivo finale al router, i valori dell'ID router e dell'ID figlio cambiano, così come RLOC16.

Conferma il nuovo stato e RLOC16 su FTD Joiner :

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

> state
router
Done
> rloc16
b800
Done

Esegui il downgrade di FTD Joiner

È possibile testare questo comportamento eseguendo il downgrade manuale di FTD Joiner da un router a un dispositivo finale. Cambia lo stato in figlio e controlla RLOC16:

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

> state child
Done
> rloc16
0c03
Done

Tornando al Commissario FTD , il falegname FTD dovrebbe ora apparire nella tabella figlio (ID = 3). Potrebbe anche essere in entrambi durante le transizioni:

## 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 .

Rimuovi il leader

Il Leader è autoeletto tra tutti i Thread Router. Ciò significa che se il Leader corrente viene rimosso dalla rete Thread, uno degli altri Router diventerà il nuovo Leader.

Sul Commissario FTD , chiudi Thread per rimuoverlo dalla rete Thread:

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

> thread stop
Done
> ifconfig down
Done

Entro due minuti, FTD Joiner diventa il nuovo Thread leader. Controllare 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 il tavolo del bambino. Notare che c'è un nuovo RLOC16. Questo è RCP Joiner, come indicato dal suo ID e dal MAC esteso. Per mantenere unita la rete Thread, ha cambiato i Router principali, da FTD Commissioner a FTD Joiner. Ciò si traduce in 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

Potrebbe essere necessario attendere alcuni minuti affinché RCP Joiner si colleghi a FTD Joiner da bambino. Controllare lo stato e RLOC16 per confermare che:

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

> state
child
> rloc16
b801

Ricollega il Commissario FTD

Una rete di thread con due nodi non è molto divertente. Riportiamo online il Commissario FTD.

Sul Commissario FTD , riavvia il thread:

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

> ifconfig up
Done
> thread start
Done

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

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

> state
router
Done

Controllare il router e le tabelle figlie su 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 di thread è composta di nuovo da tre nodi.

La gestione di una rete Thread con più dispositivi su diversi terminali o finestre dello schermo può essere complicata. Utilizzare questi suggerimenti per "ripristinare" lo stato della rete o dell'area di lavoro in caso di problemi.

Schermo

Se ti perdi nella tua configurazione (troppe finestre dello schermo, o schermate all'interno dello schermo), continua a uccidere le finestre dello schermo con Ctrl + a → k finché non ne esistono e screen -ls sulla riga di comando restituisce No Sockets found . Quindi ricreare le finestre dello schermo per ogni dispositivo. Gli stati del dispositivo vengono mantenuti anche quando lo schermo viene interrotto.

Nodi di thread

Se la topologia di rete thread non è come descritto in questo Codelab, o nodi staccare per qualche motivo (forse perché la macchina Linux li alimenta è andato a dormire), è meglio far cadere Filo, cancellare le credenziali di rete, e ricominciare dal Crea il passaggio Rete di thread .

Per ripristinare gli FTD:

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

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

L'RCP può essere ripristinato allo stesso modo tramite ot-ctl :

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

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

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

Indirizzo IPv6	Scopo	Spedito a
`ff02::1`	Link-Local	Tutti gli FTD e i MED
`ff02::2`	Link-Local	Tutti gli FTD e i router di confine
`ff03::1`	Mesh-Local	Tutti gli FTD e i MED
`ff03::2`	Mesh-Local	Tutti gli FTD e i router di confine

Dal momento che non stiamo utilizzando un router di confine in questo Codelab, concentriamoci sui due indirizzi multicast FTD e MED.

Link-Local

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

Ping ff02::1 dal Commissario FTD :

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

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

Ci sono altri due dispositivi nella rete (FTD Joiner e RCP Joiner), ma il Commissario FTD ha ricevuto solo una risposta, dal Link-Local Address (LLA) di FTD Joiner. Ciò significa che FTD Joiner è l'unico dispositivo che il Commissario FTD può raggiungere con un solo salto.

Ora ping 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 per gli altri dispositivi, possiamo vedere che il primo (che termina con 4b1d ) è l'LLA del Commissario FTD, e il secondo (che termina con 943b ) è l'LLA di RCP Joiner.

Ciò significa che l'FTD Joiner è direttamente collegato sia all'FTD Commissioner che all'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 dal Commissario FTD :

## 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 dall'FTD Joiner's Routing Locator (RLOC, che termina con b800 ) e una b800 Joiner's Mesh-Local EID (ML-EID, che termina con d55f ). Questo perché l'ambito mesh locale comprende l'intera rete Thread. Indipendentemente da dove si trovi un dispositivo nella rete, verrà sottoscritto all'indirizzo ff03::1 .

Ping 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

Annotare il tempo di risposta per RCP Joiner in entrambe le uscite ping. L'RCP Joiner ha impiegato molto più tempo per raggiungere l'FTD Commissioner (68 ms) che per raggiungere l'FTD Joiner (23 ms). Questo perché deve fare due salti per raggiungere il Commissario FTD, rispetto a un salto per l'FTD Joiner.

Potresti anche aver notato che il ping multicast locale della mesh ha risposto con RLOC solo per i due FTD, non per 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

Uno dei servizi applicativi forniti da OpenThread è il protocollo UDP (User Datagram Protocol), un protocollo di livello di trasporto. Un'applicazione costruita su OpenThread potrebbe utilizzare l'API UDP per passare messaggi tra i nodi in una rete Thread o ad altri dispositivi in una rete esterna (come Internet, se la rete Thread presenta un Border Router).

I socket UDP vengono esposti tramite la CLI di OpenThread. Usiamolo per passare messaggi tra i due FTD.

Ottieni l'indirizzo Mesh-Local EID per FTD Joiner . Utilizziamo questo indirizzo perché è raggiungibile da qualsiasi punto all'interno 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 collegalo a un socket per qualsiasi indirizzo IPv6:

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

> udp open
Done
> udp bind :: 1212

Passa a FTD Commissioner , avvia UDP e connettiti alla presa che hai impostato su FTD Joiner, utilizzando il suo ML-EID:

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

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

La connessione UDP dovrebbe essere attiva tra i due nodi. Invia un messaggio dal Commissario FTD:

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

> udp send hellothere
Done

Su FTD Joiner , il messaggio UDP è stato ricevuto!

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

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

Hai creato una rete di thread fisica!

Ora sai:

la differenza tra i tipi di dispositivo Thread, i ruoli e gli ambiti
come i dispositivi Thread gestiscono i propri stati all'interno della rete
come passare semplici messaggi tra i nodi utilizzando UDP

Prossimi passi

Partendo da questo Codelab, prova i seguenti esercizi:

Riflash la scheda FTD Joiner come MTD usando il binario ot-cli-mtd e osserva che non si aggiorna mai a un router o cerca di diventare il leader
Aggiungi più dispositivi (prova una piattaforma diversa!) Alla rete e traccia la topologia utilizzando router e tabelle figlie, insieme ai ping agli indirizzi multicast
Usa pyspinel per controllare il PCN
Converti l'NCP in un Border Router utilizzando OpenThread Border Router e collega la tua rete Thread a Internet

Ulteriore lettura

Dai un'occhiata a openthread.io e GitHub per una varietà di risorse OpenThread, tra cui:

Piattaforme supportate : scopri tutte le piattaforme che supportano OpenThread
Build OpenThread : ulteriori dettagli sulla creazione e configurazione di OpenThread
Thread Primer - copre tutti i concetti di Thread presenti in questo Codelab

Riferimento: