Créez un réseau Thread avec les cartes nRF52840 et OpenThread

OpenThread publié par Google est une implémentation open-source du protocole réseau Thread® . Google Nest a lancé OpenThread pour rendre la technologie utilisée dans les produits Nest largement accessible aux développeurs afin d'accélérer le développement de produits pour la maison connectée.

La spécification Thread définit un protocole de communication appareil à appareil sans fil fiable, sécurisé et de faible puissance basé sur IPv6 pour les applications domestiques. OpenThread implémente toutes les couches de réseau Thread, y compris IPv6, 6LoWPAN, IEEE 802.15.4 avec sécurité MAC, établissement de liens maillés et routage maillé.

Dans ce Codelab, vous programmez OpenThread sur du matériel réel, créez et gérez un réseau Thread et passez des messages entre les nœuds.

Ce que tu apprendras

Construction et flashage des fichiers binaires de l'interface CLI OpenThread sur les cartes de développement
Construire un RCP composé d'une machine Linux et d'une carte de développement
Communication avec un RCP à l'aide d'OpenThread Daemon et d' ot-ctl
Gérer manuellement les nœuds Thread avec Screen et la CLI OpenThread
Mise en service sécurisée des appareils sur un réseau Thread
Fonctionnement de la multidiffusion IPv6
Passer des messages entre les nœuds Thread avec UDP

Ce dont vous aurez besoin

Matériel:

3 cartes de développement Nordic Semiconductor nRF52840
3 câbles USB vers Micro-USB pour connecter les cartes
Une machine Linux avec au moins 3 ports USB

Logiciel:

Chaîne d'outils GNU
Outils de ligne de commande Nordic nRF5x
Logiciel Segger J-Link
OpenThread
Git

Sauf indication contraire, le contenu de ce Codelab est concédé sous licence Creative Commons Attribution 3.0 , et les exemples de code sont concédés sous licence Apache 2.0 .

Simulation OpenThread

Avant de commencer, vous voudrez peut-être parcourir le OpenThread Simulation Codelab , pour vous familiariser avec les concepts de base de Thread et la CLI OpenThread.

Terminaux de port série

Vous devez savoir comment vous connecter à un port série via un terminal. Ce Codelab utilise Screen et fournit un aperçu de l'utilisation, mais tout autre logiciel de terminal peut être utilisé.

Machine Linux

Ce Codelab a été conçu pour utiliser une machine Linux basée sur i386 ou x86 pour servir d'hôte à un périphérique Thread RCP (Radio Co-Processor) et pour flasher toutes les cartes de développement Thread. Toutes les étapes ont été testées sur Ubuntu 14.04.5 LTS (Trusty Tahr).

Cartes Nordic Semiconductor nRF52840

Ce Codelab utilise trois cartes PDK nRF52840 .

Installez SEGGER J-Link

Nous utilisons SEGGER J-Link pour programmer les cartes nRF52840, qui ont des modules JTAG intégrés. Installez-le sur votre machine Linux.

Télécharger le logiciel et le pack de documentation J-Link

Téléchargez le package approprié pour votre machine et installez-le à l'emplacement approprié. Sous Linux, il s'agit de /opt/SEGGER/JLink .

Installer les outils de ligne de commande nRF5x

Les outils de ligne de commande nRF5x vous permettent de flasher les binaires OpenThread sur les cartes nRF52840. Installez le build nRF5x-Command-Line-Tools- <OS> approprié sur votre machine Linux.

Télécharger les outils de ligne de commande nRF5x

Placez le package extrait dans le dossier racine ~/

Installer la chaîne d'outils ARM GNU

La chaîne d'outils ARM GNU est utilisée pour la construction.

Télécharger l'archive portable ARM GNU Toolchain

Nous vous recommandons de placer l'archive extraite dans /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/ sur votre machine Linux. Suivez les instructions du fichier readme.txt archive pour les instructions d'installation.

Écran d'installation (facultatif)

Screen est un outil simple pour accéder aux appareils connectés par un port série. Ce Codelab utilise Screen, mais vous pouvez utiliser n'importe quelle application de terminal de port série que vous souhaitez.

$ sudo apt-get install screen

OpenThread

Clonez et installez OpenThread. Les commandes d' bootstrap garantissent que la chaîne d'outils est installée et que l'environnement est correctement configuré:

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

Construisez le démon OpenThread:

$ make -f src/posix/Makefile-posix DAEMON=1

Vous êtes maintenant prêt à créer et flasher OpenThread sur les cartes nRF52840.

Construire et flasher

Créez l'exemple OpenThread nRF52840 avec Joiner et la fonctionnalité USB native. Un appareil utilise le rôle Joiner pour être authentifié et mis en service en toute sécurité sur un réseau Thread. L'USB natif permet l'utilisation de l'USB CDC ACM comme transport série entre le nRF52840 et l'hôte.

Nettoyez toujours le dépôt des versions précédentes en exécutant make clean .

$ cd ~/src/openthread
$ make -f examples/Makefile-nrf52840 clean
$ make -f examples/Makefile-nrf52840 JOINER=1 USB=1

Accédez au répertoire contenant le binaire OpenThread RCP et convertissez-le au format hexadécimal:

$ cd ~/src/openthread/output/nrf52840/bin
$ arm-none-eabi-objcopy -O ihex ot-rcp ot-rcp.hex

Branchez le câble USB au port de débogage Micro-USB à côté de la broche d'alimentation externe sur la carte nRF52840, puis branchez-le sur la machine Linux. Réglez le commutateur de source d' alimentation nRF de la carte nRF52840 sur VDD . Lorsqu'il est correctement connecté, la LED5 est allumée .

S'il s'agit de la première carte connectée à la machine Linux, elle apparaît sous la forme de port série /dev/ttyACM0 (toutes les cartes ttyACM utilisent ttyACM comme identificateur de port série).

$ ls /dev/ttyACM*
/dev/ttyACM0

Notez le numéro de série de la carte nRF52840 utilisée pour le RCP:

Accédez à l'emplacement des outils de ligne de commande nRFx et flashez le fichier hexadécimal OpenThread RCP sur la carte nRF52840, en utilisant le numéro de série de la carte:

$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --chiperase --program \
       ~/openthread/output/nrf52840/bin/ot-rcp.hex --reset

La sortie suivante est générée en cas de succès:

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.

Étiquetez le tableau "RCP" afin que plus tard vous ne confondiez pas les rôles du tableau.

Connectez-vous à USB natif

Étant donné que la version OpenThread RCP permet l'utilisation de l'ACM CDC USB native comme transport série, vous devez utiliser le port USB nRF sur la carte nRF52840 pour communiquer avec l'hôte RCP (machine Linux).

Détachez l'extrémité Micro-USB du câble USB du port de débogage de la carte nRF52840 flashée, puis rebranchez-la au port USB Micro-USB nRF à côté du bouton RESET . Réglez le commutateur de source d'alimentation nRF sur USB .

Démarrez OpenThread Daemon

Dans la conception RCP, utilisez OpenThread Daemon pour communiquer avec et gérer le périphérique Thread. Démarrez ot-daemon avec l'indicateur détaillé -v pour voir la sortie du journal et confirmer qu'il est en cours d'exécution:

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

En cas de succès, ot-daemon en mode détaillé génère une sortie similaire à ce qui suit:

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

Laissez cette fenêtre de terminal ouverte pour que les journaux d' ot-daemon puissent être visualisés.

Utilisez ot-ctl pour communiquer avec le nœud RCP. ot-ctl utilise le même CLI que l'application CLI OpenThread. Par conséquent, vous pouvez contrôler les nœuds ot-daemon de la même manière que les autres périphériques Thread simulés.

Dans une deuxième fenêtre de terminal, démarrez ot-ctl :

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

Vérifiez l' state du nœud 2 (le nœud RCP) que vous avez démarré avec ot-daemon :

> state
disabled
Done

Les deux autres nœuds Thread utilisés dans ce Codelab sont des périphériques Full Thread (FTD) sur la conception standard de System-on-Chip (SoC). Ils n'utilisent pas wpantund et l'utilisateur les gère manuellement avec l'OpenThread CLI.

Un appareil fonctionne comme le commissaire, pour authentifier et mettre en service en toute sécurité les appareils sur ce réseau. L'autre appareil fonctionne comme un Joiner que le commissaire peut authentifier sur le réseau Thread.

Construire et flasher

Créez l'exemple OpenThread FTD pour la plate-forme nRF52840, avec les rôles Commissaire et Joiner activés:

$ cd ~/src/openthread
$ make -f examples/Makefile-nrf52840 clean
$ make -f examples/Makefile-nrf52840 COMMISSIONER=1 JOINER=1

Accédez au répertoire contenant le binaire CLI OpenThread Full Thread Device (FTD) et convertissez-le au format hexadécimal:

$ cd ~/src/openthread/output/nrf52840/bin
$ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex

Connectez le câble USB au port micro-USB à côté de la broche d'alimentation externe sur la carte nRF52840, puis branchez-le sur la machine Linux. Si le RCP est toujours connecté à la machine Linux, cette nouvelle carte doit apparaître sous la forme port série /dev/ttyACM1 (toutes les cartes ttyACM utilisent ttyACM pour l'identifiant du port série).

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

Comme précédemment, notez le numéro de série de la carte nRF52840 utilisée pour le FTD:

Accédez à l'emplacement des outils de ligne de commande nRFx et flashez le fichier hexadécimal de la CLI OpenThread sur la carte nRF52840, en utilisant le numéro de série de la carte:

$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --chiperase --program \
       ~/openthread/output/nrf52840/bin/ot-cli-ftd.hex --reset

Étiquetez le tableau «Commissaire».

Vérifier la construction

Vérifiez une construction réussie en accédant à l'interface de ligne de commande OpenThread à l'aide de l'écran GNU à partir d'une fenêtre de terminal. Les cartes nRF52840 utilisent une vitesse de transmission de 115200.

$ screen /dev/ttyACM1 115200

Dans la nouvelle fenêtre, appuyez plusieurs fois sur la touche Retour du clavier pour afficher l'invite OpenThread CLI > . Ouvrez l'interface IPv6 et vérifiez les adresses:

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

Utilisez Ctrl + a → d pour vous déconnecter de l' écran CLI du commissaire FTD et revenir au terminal Linux afin que la carte suivante puisse être flashée. Pour entrer à nouveau dans la CLI à tout moment, utilisez screen -r partir de la ligne de commande. Pour voir une liste des écrans disponibles, utilisez screen -ls :

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

Configurer le joint FTD

Répétez le processus ci-dessus pour flasher la troisième carte nRF52840, en utilisant la version existante ot-cli-ftd.hex .

Si les deux autres nœuds sont connectés à la machine Linux lorsque cette troisième carte est connectée, elle doit apparaître comme port série /dev/ttyACM2 :

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

Étiquetez le tableau «Joiner».

Lors de la vérification à l'aide de Screen, au lieu de créer une nouvelle instance de Screen à partir de la ligne de commande, rattachez-la à celle existante et créez une nouvelle fenêtre (que vous avez utilisée pour le commissaire FTD):

$ screen -r

Créez la nouvelle fenêtre dans Screen avec Ctrl + a → c **. ** Une nouvelle invite de ligne de commande apparaît. Accédez à l'interface de ligne de commande OpenThread pour le joint FTD:

$ screen /dev/ttyACM2 115200

Dans cette nouvelle fenêtre, appuyez plusieurs fois sur la touche Retour du clavier pour afficher l'invite OpenThread CLI > . Ouvrez l'interface IPv6 et vérifiez les adresses:

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

Maintenant que l'interface de ligne de commande FTD Joiner est dans la même instance de Screen que le commissaire FTD, vous pouvez basculer entre eux en utilisant Ctrl + a → n .

Utilisez Ctrl + a → d à tout moment pour quitter l'écran.

À l'avenir, vous basculerez fréquemment entre les périphériques Thread, alors assurez-vous qu'ils sont tous en direct et facilement accessibles. Jusqu'à présent, nous avons utilisé Screen pour accéder aux deux FTD, et cet outil permet également de partager l'écran sur la même fenêtre de terminal. Utilisez ceci pour voir comment un nœud réagit aux commandes émises sur un autre.

Idéalement, vous devriez avoir quatre fenêtres facilement disponibles:

service / journaux ot-daemon
RCP Joiner via ot-ctl
Commissaire FTD via OpenThread CLI
Joiner FTD via OpenThread CLI

Si vous souhaitez utiliser votre propre configuration ou outil de terminal / port série, n'hésitez pas à passer à l'étape suivante. Configurez les fenêtres de terminal pour tous les appareils de la manière qui vous convient le mieux.

Utilisation de l'écran

Pour faciliter l'utilisation, ne démarrez qu'une seule session Screen. Vous devriez déjà en avoir un à partir du moment où vous avez configuré les deux FTD.

Toutes les commandes dans Screen commencent par Ctrl + a.

Commandes d'écran de base:

Rattacher à la session Screen (à partir de la ligne de commande)	`screen -r`
Quitter la session Screen	Ctrl + a → `d`
Créer une nouvelle fenêtre dans la session Screen	Ctrl + a → `c`
Basculer entre les fenêtres dans la même session d'écran	Ctrl + a → `n` (avant) Ctrl + a → `p` (arrière)
Tuez la fenêtre actuelle dans la session Screen	Ctrl + a → `k`

Écran divisé

Avec Screen, vous pouvez diviser le terminal en plusieurs fenêtres:

Les commandes de l' screen sont accessibles en utilisant Ctrl + a. Chaque commande doit commencer par cette combinaison de touches d'accès.

Si vous avez suivi exactement le Codelab, vous devriez avoir deux fenêtres (FTD Commissioner, FTD Joiner) sur la même instance Screen. Pour diviser l'écran entre les deux, entrez d'abord votre session Screen existante:

$ screen -r

Vous devriez être sur l'un des appareils FTD. Suivez ces étapes dans l'écran:

Ctrl + a → S pour diviser la fenêtre horizontalement
Ctrl + a → Tab pour déplacer le curseur vers la nouvelle fenêtre vide
Ctrl + a → n pour basculer cette nouvelle fenêtre vers la suivante
Si c'est le même que la fenêtre du haut, Ctrl + a → n nouveau pour afficher l'autre périphérique FTD

Ils sont maintenant tous les deux visibles. Basculez entre eux en utilisant Ctrl + a → Tab . Il est recommandé de renommer chaque fenêtre avec Ctrl + a → A pour éviter toute confusion.

Utilisation avancée

Pour diviser davantage l'écran en quadrants et afficher les journaux ot-daemon et RCP Joiner ot-ctl , ces services doivent être démarrés dans cette même instance Screen. Pour ce faire, arrêtez ot-daemon et quittez ot-ctl , et redémarrez-les dans les nouvelles fenêtres d'écran (Ctrl + a → c ).

Cette configuration n'est pas requise et reste un exercice pour l'utilisateur.

Fractionner et naviguer entre les fenêtres avec les commandes suivantes:

Créer une nouvelle fenêtre	Ctrl + a → `c`
Diviser la fenêtre verticalement	Ctrl + a →
Diviser la fenêtre horizontalement	Ctrl + a → `S`
Passer à la fenêtre suivante affichée	Ctrl + a → `Tab`
Basculer la fenêtre affichée vers l'avant ou vers l'arrière	Ctrl + a → `n` ou `p`
Renommer la fenêtre actuelle	Ctrl + a → `A`

Quittez Screen à tout moment avec Ctrl + a → d et rattachez-le avec screen -r depuis la ligne de commande.

Pour plus d'informations sur Screen, consultez la référence rapide GNU Screen .

Maintenant que toutes les fenêtres et tous les écrans de votre terminal sont configurés, créons notre réseau Thread. Sur le commissaire FTD , créez un nouvel ensemble de données opérationnelles et validez-le en tant que fichier actif. Le jeu de données opérationnel est la configuration du réseau Thread que vous créez.

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

Notez la clé principale 1234c0de7ab51234c0de7ab51234c0de qui sera utilisée plus tard.

Validez cet ensemble de données en tant qu'actif:

> dataset commit active
Done

Affichez l'interface IPv6:

> ifconfig up
Done

Démarrez le fonctionnement du protocole Thread:

> thread start
Done

Après un moment, vérifiez l'état de l'appareil. Ce devrait être le chef. Obtenez également le RLOC16 pour référence future.

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

> state
leader
Done
> rloc16
0c00
Done

Vérifiez les adresses IPv6 de l'appareil:

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

Le réseau "codelab" est désormais visible lorsqu'il est scanné à partir d'autres périphériques Thread.

Depuis ot-ctl sur le 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 |

À partir de l'interface de ligne de commande OpenThread sur le joint FTD :

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

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

Si le réseau "codelab" n'apparaît pas dans la liste, essayez à nouveau de numériser.

Vous pouvez noter que dans les deux scans, le réseau semble ne pas être joignable (colonne J sur RCP Joiner et FTD Joiner). Cela signifie uniquement que Thread Commissioning n'est pas actif sur le réseau. Il peut toujours être joint hors bande, en entrant manuellement la clé principale du réseau dans le dispositif de connexion.

Ajoutons le RCP Joiner au réseau Thread que nous venons de créer, en utilisant un processus hors bande. Rechercher des réseaux sur le 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 |

Pour rejoindre, définissez la clé principale du réseau (que nous venons d'obtenir du commissaire FTD) sur le RCP Joiner dans son jeu de données actif.

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

> dataset masterkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

Vérifiez l'ensemble de données pour vous assurer qu'il est correctement défini.

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

> dataset
Master Key: 1234c0de7ab51234c0de7ab51234c0de

Amenez Thread pour que le RCP Joiner rejoigne le réseau "codelab". Attendez quelques secondes, vérifiez l'état, RLOC16 et ses adresses 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

Notez l'adresse IPv6 Mesh-Local ( fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f ici), vous l'utiliserez plus tard.

De retour sur le commissaire FTD , vérifiez le routeur et les tables enfants pour confirmer que les deux périphériques font partie du même réseau. Utilisez le RLOC16 pour identifier le joint RCP.

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

Envoyez un ping à l'adresse locale du maillage du RCP Joiner (l'adresse Mesh-Local obtenue à partir de la sortie ipaddr du RCP Joiner) pour vérifier la connectivité:

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

Nous avons maintenant un réseau Thread composé de deux nœuds, illustré par ce diagramme de topologie:

Diagrammes de topologie

Au fur et à mesure que vous travaillez sur le reste du Codelab, nous afficherons un nouveau diagramme de topologie de thread chaque fois que l'état du réseau change. Les rôles de nœud sont indiqués comme suit:

Les routeurs sont toujours des pentagones et les terminaux sont toujours des cercles. Les nombres sur chaque nœud représentent l'ID de routeur ou l'ID enfant affiché dans la sortie CLI, en fonction du rôle et de l'état actuels de chaque nœud à ce moment.

Ajoutons maintenant le troisième périphérique Thread au réseau "codelab". Cette fois, nous allons utiliser le processus de mise en service intrabande plus sécurisé. Sur le FTD Joiner , recherchez le réseau:

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

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

Un 0 dans la colonne J indique que Thread Commissioning n'est pas actif sur l'appareil.

Soyons précis lors de la mise en service de cet appareil suivant et autorisons uniquement le joint FTD à rejoindre. Toujours sur le FTD Joiner, récupérez l' eui64 , afin que le commissaire FTD puisse l'identifier:

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

> eui64
2f57d222545271f1
Done

Sur le commissaire FTD , démarrez le commissaire et spécifiez l' eui64 de l'appareil qui peut se joindre, ainsi que les informations d'identification de joint. Les informations d'identification du joint sont une phrase secrète spécifique à l'appareil.

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

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

Basculez vers le joint FTD et effectuez une nouvelle analyse:

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

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

Comme indiqué par le 1 dans la colonne J, Thread Commissioning est maintenant actif sur le réseau. Démarrez le rôle de joint avec les informations d'identification de joint que vous venez de configurer sur le commissaire FTD:

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

> ifconfig up
Done
> joiner start J01NME
Done

En l'espace d'une minute environ, vous obtenez une confirmation d'une authentification réussie:

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

>
Join success

Ouvrez Thread pour que le joint FTD rejoigne le réseau "codelab" et vérifiez immédiatement l'état et le RLOC16:

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

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

Vérifiez les adresses IPv6 de l'appareil. Notez qu'il n'y a pas d'ALOC. C'est parce que cet appareil n'est pas le leader, ni ne détient un rôle spécifique à Anycast qui nécessite 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)

Passez immédiatement au commissaire FTD et vérifiez le routeur et les tables enfants pour confirmer que trois périphériques existent dans le réseau "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

Basé sur le RLOC16, le joint FTD s'est attaché au réseau en tant que périphérique final (enfant). Voici notre topologie mise à jour:

Les périphériques Thread de ce Codelab sont un type spécifique de périphérique Full Thread (FTD) appelé un Router Eligible End Device (REED). Cela signifie qu'ils peuvent fonctionner comme un routeur ou un périphérique final, et peuvent se promouvoir d'un périphérique final à un routeur.

Thread peut prendre en charge jusqu'à 32 routeurs, mais essaie de maintenir le nombre de routeurs entre 16 et 23. Si un REED se connecte en tant que périphérique final (enfant) et que le nombre de routeurs est inférieur à 16, après une période aléatoire de deux minutes, il se promeut automatiquement auprès d'un routeur.

Si vous aviez deux enfants dans votre réseau Thread après avoir ajouté le FTD Joiner, attendez au moins deux minutes, puis revérifiez le routeur et les tables enfants sur le commissaire 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

Le e6cdd2d93249a243 FTD (Extended MAC = e6cdd2d93249a243 ) s'est promu en tant que routeur. Notez que le RLOC16 est différent ( b800 au lieu de 0c02 ). C'est parce que le RLOC16 est basé sur l'ID de routeur et l'ID d'enfant d'un périphérique. Lorsqu'il passe du périphérique final au routeur, ses valeurs d'ID de routeur et d'ID enfant changent, tout comme le RLOC16.

Confirmez le nouvel état et RLOC16 sur le joint FTD :

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

> state
router
Done
> rloc16
b800
Done

Rétrograder le joint FTD

Vous pouvez tester ce comportement en rétrogradant manuellement le joint FTD d'un routeur à un périphérique final. Changez l'état en enfant et vérifiez le RLOC16:

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

> state child
Done
> rloc16
0c03
Done

De retour sur le commissaire FTD , le joint FTD devrait maintenant apparaître dans la table enfant (ID = 3). Il peut même être dans les deux pendant la transition:

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

Après un certain temps, il reviendra sur un routeur avec un RLOC de b800 .

Retirer le chef

Le leader est auto-élu parmi tous les routeurs de threads. Cela signifie que si le leader actuel est retiré du réseau Thread, l'un des autres routeurs deviendra le nouveau leader.

Sur le commissaire FTD , arrêtez Thread pour le supprimer du réseau Thread:

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

> thread stop
Done
> ifconfig down
Done

En moins de deux minutes, le joint FTD devient le nouveau chef de file. Vérifiez l'état et les adresses IPv6 du joint FTD pour vérifier:

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

Vérifiez la table enfant. Notez qu'il y a un nouveau RLOC16. Il s'agit du RCP Joiner, comme indiqué par son ID et son MAC étendu. Afin de garder le réseau Thread ensemble, il a commuté les routeurs parents, du commissaire FTD au joint FTD. Il en résulte un nouveau RLOC16 pour le RCP Joiner (car son ID de routeur a changé, de 3 à 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

Vous devrez peut-être attendre quelques minutes pour que le menuisier RCP se connecte au menuisier FTD en tant qu'enfant. Vérifiez l'état et le RLOC16 pour confirmer que:

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

> state
child
> rloc16
b801

Rattacher le commissaire FTD

Un réseau Thread avec deux nœuds n'est pas très amusant. Remettons le commissaire FTD en ligne.

Sur le commissaire FTD , redémarrez Thread:

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

> ifconfig up
Done
> thread start
Done

En moins de deux minutes, il se reconnecte automatiquement au réseau «codelab» en tant que périphérique final, puis se présente comme un routeur.

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

> state
router
Done

Vérifiez le routeur et les tables enfants sur le joint FTD pour vérifier:

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

Notre réseau Thread se compose à nouveau de trois nœuds.

La gestion d'un réseau Thread avec plusieurs appareils sur différents terminaux ou fenêtres d'écran peut être compliquée. Utilisez ces conseils pour «réinitialiser» l'état du réseau ou de votre espace de travail si vous rencontrez des problèmes.

Écran

Si jamais vous vous perdez dans votre configuration (trop de fenêtres d'écran ou d'écrans dans l'écran), continuez à tuer les fenêtres d'écran avec Ctrl + a → k jusqu'à ce screen -ls n'en existent pas et screen -ls sur la ligne de commande screen -ls No Sockets found . Puis recréez les fenêtres d'écran pour chaque appareil. Les états de l'appareil sont conservés même lorsque Screen est tué.

Nœuds de thread

Si la topologie du réseau Thread n'est pas celle décrite dans ce Codelab, ou si les nœuds se déconnectent pour une raison quelconque (peut-être parce que la machine Linux qui les alimente s'est mise en veille), il est préférable de désactiver Thread, d'effacer les informations d'identification réseau et de recommencer à partir de Créer l' étape du réseau Thread .

Pour réinitialiser les FTD:

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

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

Le RCP peut être réinitialisé de la même manière via ot-ctl :

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

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

La multidiffusion est utilisée pour communiquer des informations à un groupe d'appareils à la fois. Dans un réseau Thread, des adresses spécifiques sont réservées pour une utilisation multicast avec différents groupes d'appareils, en fonction de l'étendue.

Adresse IPv6	Portée	Livré à
`ff02::1`	Lien local	Tous les FTD et MED
`ff02::2`	Lien local	Tous les FTD et routeurs de bordure
`ff03::1`	Mesh-Local	Tous les FTD et MED
`ff03::2`	Mesh-Local	Tous les FTD et routeurs de bordure

Puisque nous n'utilisons pas de routeur frontalier dans ce Codelab, concentrons-nous sur les deux adresses de multidiffusion FTD et MED.

Lien local

L'étendue Link-Local comprend toutes les interfaces Thread accessibles par une seule transmission radio, ou un seul «bond». La topologie du réseau détermine les périphériques qui répondent à un ping à l'adresse de multidiffusion ff02::1 .

Ping ff02::1 du commissaire FTD :

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

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

Il y a deux autres dispositifs dans le réseau (FTD Joiner et RCP Joiner), mais le commissaire FTD n'a reçu qu'une seule réponse, de l'adresse Link-Local du FTD Joiner (LLA). Cela signifie que le FTD Joiner est le seul appareil que le commissaire FTD peut atteindre avec un seul bond.

Maintenant, ff02::1 ping à ff02::1 depuis le joint FTD :

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

Deux réponses! En vérifiant les adresses IPv6 des autres appareils, nous pouvons voir que le premier (se terminant par 4b1d ) est le LLA du commissaire FTD et le second (se terminant par 943b ) est le LLA du RCP Joiner.

Cela signifie que le joint FTD est directement connecté au commissaire FTD et au joint RCP, ce qui confirme notre topologie.

Mesh-Local

La portée Mesh-Local comprend toutes les interfaces Thread accessibles dans le même réseau Thread. Voyons les réponses à un ping à l'adresse de multidiffusion ff03::1 .

Ping ff03::1 du commissaire 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

Cette fois, le commissaire FTD a reçu deux réponses, une du localisateur de routage du menuisier FTD (RLOC, se terminant par b800 ) et une de l'EID Mesh-Local du RCP (ML-EID, se terminant par d55f ). C'est parce que la portée locale maillée comprend tout le réseau Thread. Peu importe où dans le réseau un périphérique se trouve, il sera abonné à l'adresse ff03::1 .

Ping ff03::1 partir du ff03::1 FTD pour confirmer le même comportement:

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

Notez le temps de réponse du RCP Joiner dans les deux sorties ping. Le RCP Joiner a mis beaucoup plus de temps pour atteindre le commissaire FTD (68 ms) que pour atteindre le FTD Joiner (23 ms). C'est parce qu'il doit faire deux sauts pour atteindre le commissaire FTD, comparé à un saut pour le menuisier FTD.

Vous avez peut-être également remarqué que le ping de multidiffusion locale de maillage a répondu avec le RLOC uniquement pour les deux FTD, pas pour le RCP Joiner. En effet, les FTD sont des routeurs au sein du réseau, tandis que le RCP est un périphérique final.

Vérifiez l'état du RCP Joiner pour confirmer:

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

> state
child

L'un des services d'application fournis par OpenThread est le protocole UDP (User Datagram Protocol), un protocole de couche de transport. Une application basée sur OpenThread peut utiliser l'API UDP pour transmettre des messages entre les nœuds d'un réseau Thread, ou à d'autres périphériques d'un réseau externe (comme Internet, si le réseau Thread dispose d'un routeur frontalier).

Les sockets UDP sont exposés via l'interface de ligne de commande OpenThread. Utilisons-le pour passer des messages entre les deux FTD.

Obtenez l'adresse EID Mesh-Local pour le joint FTD . Nous utilisons cette adresse car elle est accessible de n'importe où dans le réseau 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

Démarrez UDP et liez-le à un socket pour n'importe quelle adresse IPv6:

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

> udp open
Done
> udp bind :: 1212

Basculez vers le commissaire FTD , démarrez UDP et connectez-vous au socket que vous avez configuré sur le joint FTD, en utilisant son ML-EID:

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

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

La connexion UDP doit être active entre les deux nœuds. Envoyez un message du commissaire FTD:

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

> udp send hellothere
Done

Sur le joint FTD , le message UDP a été reçu!

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

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

Vous avez créé un réseau Thread physique!

Vous savez maintenant:

la différence entre les types de périphériques Thread, les rôles et les étendues
comment les périphériques Thread gèrent leurs états sur le réseau
comment passer des messages simples entre les nœuds en utilisant UDP

Prochaines étapes

À partir de ce Codelab, essayez les exercices suivants:

Reflash la carte de jointure FTD en tant que MTD en utilisant le binaire ot-cli-mtd , et observez qu'elle ne se met jamais à niveau vers un routeur ou ot-cli-mtd jamais de devenir le leader
Ajoutez plus de périphériques (essayez une plate-forme différente!) Au réseau et esquissez la topologie en utilisant le routeur et les tables enfants, ainsi que des pings aux adresses de multidiffusion
Utilisez pyspinel pour contrôler le NCP
Convertissez le NCP en un routeur frontalier à l'aide du routeur frontière OpenThread et connectez votre réseau Thread à Internet

Lectures complémentaires

Consultez openthread.io et GitHub pour une variété de ressources OpenThread, notamment:

Plateformes prises en charge - découvrez toutes les plateformes prenant en charge OpenThread
Construire OpenThread - plus de détails sur la construction et la configuration d'OpenThread
Thread Primer - couvre tous les concepts de thread présentés dans ce Codelab

Référence: