Créer un réseau Thread avec des cartes nRF52840 et OpenThread

À propos de cet atelier de programmation

88 minutes

Dernière mise à jour : 1 août 2023

Rédigé par Jeff Bumgardner

1. Introduction

OpenThread publié par Google est une implémentation Open Source du protocole réseau Thread®. Google Nest a lancé OpenThread afin de 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 sans fil d'appareil à appareil fiable, sécurisé et à faible consommation d'énergie basé sur IPv6 pour les applications domestiques. OpenThread implémente toutes les couches réseau Thread, y compris IPv6, 6LoWPAN, IEEE 802.15.4 avec sécurité MAC, établissement de liens maillés et routage maillé.

Dans cet atelier de programmation, vous allez programmer OpenThread sur du matériel réel, créer et gérer un réseau Thread, et transmettre des messages entre les nœuds.

Points abordés

• Construire et flasher des binaires CLI OpenThread sur les cartes de développement
• Construire un RCP composé d'une machine Linux et d'une carte de développement
• Communiquer avec un RCP à l'aide du daemon OpenThread et de ot-ctl
• Gérer manuellement les nœuds Thread avec GNU Screen et la CLI OpenThread
• Mise en service sécurisée des appareils sur un réseau Thread
• Fonctionnement du multicast IPv6
• Transmettre des messages entre les nœuds Thread avec UDP

Prérequis

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 trois ports USB

Logiciels :

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

2. Premiers pas

Simulation OpenThread

Avant de commencer, vous pouvez suivre l’atelier de programmation sur la simulation OpenThread, 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. Cet atelier de programmation utilise GNU Screen et fournit un aperçu de son utilisation, mais n'importe quel autre logiciel de terminal peut être utilisé.

Machine Linux

Cet atelier de programmation a été conçu pour utiliser une machine Linux basée sur i386 ou x86 pour servir d'hôte à un appareil Thread de co-processeur radio (RCP) 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

Cet atelier de programmation utilise trois cartes PDK nRF52840.

Important:Assurez-vous que les cartes disposent d'une puissance suffisante. N'utilisez pas de répartiteur de port USB pour les connecter à la machine Linux, et désactivez les fonctionnalités de mise en veille de la machine Linux. Les cartes dont la puissance est insuffisante peuvent se comporter de manière imprévisible.

Installer SEGGER J-Link

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

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

Téléchargez le package approprié pour votre machine et installez-le au bon endroit. 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 les outils nRF5x-Command-Line-Tools-<OS> appropriés sur votre machine Linux.

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

Placez le package extrait dans le dossier racine ~/.

Remarque:Les outils de ligne de commande nRF5x ne sont pas compatibles avec les architectures ARM. Par conséquent, les cartes nRF52840 ne peuvent pas être flashées par des machines Linux à processeur ARM, telles que le Raspberry Pi 3B.

Installer la chaîne d'outils ARM GNU

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

Télécharger l'archive portable de la chaîne d'outils ARM GNU

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

Écran d'installation (facultatif)

Screen est un outil simple permettant d'accéder aux appareils connectés par un port série. Cet atelier de programmation utilise Screen, mais vous pouvez utiliser n'importe quelle application de terminal de port série.

$ sudo apt-get install screen

3. Cloner des dépôts

OpenThread

Clonez et installez OpenThread. Les commandes script/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

Créez le daemon OpenThread:

$ script/cmake-build posix -DOT_DAEMON=ON

Vous êtes maintenant prêt à construire et à flasher OpenThread sur les cartes nRF52840.

4. Configurer la jointure RCP

Compiler et flasher

Construire l'exemple OpenThread nRF52840 avec Joiner et la fonctionnalité USB native. Un appareil utilise le rôle Joiner pour s'authentifier de manière sécurisée et être mis en service sur un réseau Thread. L'USB natif permet d'utiliser le ACM CDC USB comme transport série entre le nRF52840 et l'hôte.

Commencez toujours par nettoyer le dépôt des compilations précédentes en exécutant rm -rf build.

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

Pour plus d'informations sur la compilation et la configuration d'OpenThread, consultez Créer OpenThread.

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

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

Raccordez le câble USB au port de débogage micro-USB situé à côté de la broche d'alimentation externe de la carte nRF52840, puis branchez-le sur la machine Linux. Réglez la source d'alimentation nRF de la carte nRF52840 sur VDD. Lorsque la connexion est correcte, le LED5 s'allume.

S'il s'agit de la première carte connectée à la machine Linux, elle apparaît sous la forme du port série /dev/ttyACM0 (toutes les cartes nRF52840 utilisent ttyACM comme identifiant 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:

Naviguez jusqu'à l'emplacement des outils de ligne de commande nRFx et flashez le fichier hexadécimal RCP OpenThread sur la carte nRF52840, en utilisant le numéro de série de la carte. Notez que si vous omettez l'indicateur --verify, un message d'avertissement vous informe que le processus Flash peut échouer sans erreur.

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

Le résultat suivant est généré en cas de réussite:

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.

Étiqueter la carte « RCP » afin de ne pas confondre plus tard les rôles du conseil d’administration.

Se connecter au port USB natif

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

Débranchez 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 micro-USB nRF USB à côté du bouton RÉINITIALISER. Réglez le bouton de la source d'alimentation nRF sur USB.

Remarque:Lorsque la carte nRF52840 est correctement connectée à un hôte via le port USB nRF, aucun des indicateurs LED ne s'allume, même si la carte est opérationnelle.

Démarrer le daemon OpenThread

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

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

Si l'opération réussit, ot-daemon en mode détaillé génère un résultat semblable à celui-ci:

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

Laissez cette fenêtre de terminal ouverte afin que les journaux de ot-daemon puissent être consultés.

Utilisez ot-ctl pour communiquer avec le nœud RCP. ot-ctl utilise la 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 appareils Thread simulés.

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

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

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

> state
disabled
Done

5. Configurer les FTD

Les deux autres nœuds Thread utilisés dans cet atelier de programmation sont des appareils FTD (Full Thread) sur la conception standard du SoC (System-on-Chip). Dans un cadre de production, vous pouvez utiliser wpantund, un pilote d'interface réseau de niveau production, pour contrôler les instances NCP OpenThread, mais dans cet atelier de programmation, nous utiliserons ot-ctl, la CLI OpenThread.

Un appareil fait office de commissaire pour authentifier et mettre en service les appareils sur ce réseau de manière sécurisée. L'autre appareil fonctionne comme un Joiner (Joiner) que le Commissaire peut authentifier auprès du réseau Thread.

Compiler et flasher

Créez l'exemple OpenThread FTD pour la plateforme nRF52840, avec les rôles de commissaire et de jointure activés:

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

Idéalement, vous devriez créer OpenThread avec uniquement la fonctionnalité souhaitée activée. Par exemple, FTD Joiner n'utiliserait que le commutateur JOINER=1. Pour faciliter l'utilisation dans cet atelier de programmation, créez une image unique avec les deux rôles afin que l'image puisse être utilisée pour les deux FTD.

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

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

Raccordez le câble USB au port micro-USB situé à côté de la broche d'alimentation externe de 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 du port série /dev/ttyACM1 (toutes les cartes nRF52840 utilisent ttyACM comme identifiant de 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 l'appareil FTD:

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

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

Libellez le tableau "Commissaire".

Se connecter au port USB natif

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

Débranchez 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 micro-USB nRF USB à côté du bouton RÉINITIALISER. Réglez le bouton de la source d'alimentation nRF sur USB.

Remarque:Lorsque la carte nRF52840 est correctement connectée à un hôte via le port USB nRF, aucun des indicateurs LED ne s'allume, même si la carte est opérationnelle.

Vérifier la compilation

Vérifiez que le build a réussi en accédant à la CLI OpenThread à l'aide de l'écran GNU à partir d'une fenêtre de terminal. Les cartes nRF52840 utilisent un débit en bauds de 115 200.

$ screen /dev/ttyACM1 115200

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

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

Appuyez sur Ctrl+A →

d pour se détacher de l'écran de la FTD Commissioner CLI et revenir au terminal Linux afin que la carte suivante puisse être flashée. Pour accéder de nouveau à la CLI à tout moment, utilisez screen -r à partir de la ligne de commande. Pour afficher la 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 FTD Joiner

Répétez le processus ci-dessus pour flasher la troisième carte nRF52840 en utilisant le build ot-cli-ftd.hex existant. Lorsque vous avez terminé, veillez à reconnecter la carte au PC à l'aide du port USB nRF et à placer le commutateur de la source d'alimentation nRF sur VDD.

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

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

Libellez le tableau « Joiner ».

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

$ screen -r

Créez la fenêtre dans "Screen" (Écran) avec Ctrl+a → c.

Une nouvelle invite de ligne de commande s'affiche. Accédez à la CLI OpenThread pour FTD Joiner:

$ screen /dev/ttyACM2 115200

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

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

Maintenant que la CLI FTD Joiner se trouve dans la même instance d'écran que FTD Commissioner, vous pouvez passer de l'une à l'autre en appuyant sur Ctrl+a → n.

Appuyez sur Ctrl+A →

d à tout moment pour quitter l'écran.

6. Configuration de la fenêtre de terminal

À l'avenir, vous passerez fréquemment d'un appareil Thread à un autre. Assurez-vous donc qu'ils sont tous activés et facilement accessibles. Jusqu'à présent, nous avons utilisé l'écran pour accéder aux deux FTD. Cet outil permet également l'écran partagé dans la même fenêtre de terminal. Utilisez-le pour voir comment un nœud réagit aux commandes émises sur un autre nœud.

Idéalement, vous devriez disposer de quatre fenêtres facilement accessibles:

1. Service / Journaux ot-daemon
2. RCP Joiner via ot-ctl
3. FTD Commissioner via la CLI OpenThread
4. FTD Joiner via la CLI OpenThread

Si vous souhaitez utiliser votre propre configuration ou outil de terminal / port série, vous pouvez 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 plus de simplicité, ne démarrez qu'une seule session Screen. Vous devriez déjà en avoir un lorsque vous avez configuré les deux FTD.

Toutes les commandes de l'écran commencent par Ctrl+a.

Commandes de base à l'écran:

Réassocier à la session Screen (à partir de la ligne de commande)	screen -r
Quitter la session Screen	Ctrl+A → d
Créer une fenêtre dans la session Screen	Ctrl+A → c
Passer d'une fenêtre à l'autre dans la même session Screen	Ctrl+a → n (avant)Ctrl+a → p (retour)
Fermer la fenêtre actuelle de la session Screen	Ctrl+A → k

Si vous vous perdez dans votre configuration, fermez les fenêtres Screen avec Ctrl+a → k jusqu'à ce qu'il n'en existe aucune. Ensuite, démarrez une nouvelle session Screen et créez des fenêtres pour chaque appareil.

Écran partagé

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

Vous pouvez accéder aux commandes dans screen avec Ctrl+a. Chaque commande doit commencer par cette combinaison de clés d'accès.

Si vous avez suivi à la lettre l'atelier de programmation, vous devriez avoir deux fenêtres (FTD Commissioner, FTD Joiner) sur la même instance Screen. Pour partager l'écran entre les deux, accédez d'abord à votre session Screen existante:

$ screen -r

Vous devez utiliser l'un des appareils FTD. Suivez ces étapes à l'écran:

1. Ctrl+a → S pour diviser la fenêtre horizontalement
2. Ctrl+a → Tab pour déplacer le curseur dans la nouvelle fenêtre vide
3. Ctrl+a → n pour passer à la nouvelle fenêtre
4. Si elle est identique à la fenêtre supérieure, appuyez de nouveau sur Ctrl+a → n pour afficher l'autre appareil FTD.

Ils sont désormais tous les deux visibles. Passez de l'un à l'autre en appuyant sur Ctrl+a → Tab. Pour éviter toute confusion, nous vous recommandons de modifier le titre de chaque fenêtre avec Ctrl+a → A.

Utilisation avancée

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

Cette configuration n'est pas obligatoire et fait l'objet d'un exercice pour l'utilisateur.

Utilisez les commandes suivantes pour diviser les fenêtres et passer d'une fenêtre à l'autre:

Créer une fenêtre	Ctrl+A → c
Diviser la fenêtre verticalement	Ctrl+A →
Diviser la fenêtre horizontalement	Ctrl+A → S
Passer à la fenêtre affichée suivante	Ctrl+A → Tab
Avancer ou reculer la fenêtre affichée	Ctrl+a → n ou p
Renommer la fenêtre actuelle	Ctrl+A → A

Quittez l'écran à tout moment en appuyant sur Ctrl+a → d, puis réassociez-le avec screen -r depuis la ligne de commande.

Remarque: Si vous vous déconnectez de votre session Screen, la configuration de la fenêtre partagée n'est pas enregistrée.

Pour en savoir plus sur l'écran, consultez le guide de référence rapide GNU Screen.

7. Créer le réseau Thread

Important:Les informations d'identification sur vos nœuds Thread, telles que les adresses IPv6, RLOC16 et MAC, seront différentes de celles de l'exemple de résultat de cet atelier de programmation.

Maintenant que toutes vos fenêtres et tous vos écrans de terminal sont configurés, créons notre réseau Thread. Dans FTD Commissioner, créez un ensemble de données opérationnel et validez-le en tant qu'ensemble de données actif. L'ensemble de données opérationnel correspond à la configuration du réseau Thread que vous créez.

dataset init new crée un ensemble de données opérationnel avec des valeurs aléatoires. Vos valeurs seront différentes de celles présentées dans cet atelier de programmation. Remplacez les valeurs des exemples de commandes de l'atelier de programmation par les valeurs de votre ensemble de données opérationnel.

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

Notez la clé réseau 1234c0de7ab51234c0de7ab51234c0de, qui sera utilisée ultérieurement.

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

> dataset commit active
Done

Affichez l'interface IPv6:

> ifconfig up
Done

Démarrer l'opération du protocole Thread:

> thread start
Done

Patientez quelques instants, puis vérifiez l'état de l'appareil. Il doit s'agir du leader. Vous pouvez également obtenir le RLOC16 pour référence ultérieure.

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

Un nœud Thread unique possède plusieurs adresses IPv6. Pour en savoir plus, consultez la section Adressage IPv6.

L'atelier de programmation est désormais visible depuis d'autres appareils Thread.

À partir de ot-ctl sur RCP Joiner:

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

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

À partir de la CLI OpenThread sur FTD Joiner:

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

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

Si l'atelier de programmation réseau n'apparaît pas dans la liste, relancez la recherche.

8. Ajouter la jointure RCP

La mise en service des threads n'est pas active sur le réseau, ce qui signifie que nous devons ajouter le jointure RCP au réseau Thread que nous venons de créer à l'aide d'un processus de mise en service hors bande.

La mise en service intrabande se produit lorsque les identifiants du réseau sont transférés à la jointure par radio. La mise en service hors bande se produit lorsqu’ils sont fournis à la jointure par d’autres moyens (par exemple, la saisie manuelle dans la CLI OpenThread).

Pour le FTD Commissioner, nous avons noté la clé de réseau (par exemple, 1234c0de7ab51234c0de7ab51234c0de). Si vous devez rechercher à nouveau la clé réseau, exécutez la commande suivante sur FTD Commissioner:

## FTD Commissioner ##

> dataset networkkey
1234c0de7ab51234c0de7ab51234c0de
Done

Ensuite, dans RCP Joiner, définissez la clé réseau de l'ensemble de données actif sur la clé réseau FTD Commissioner:

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

> dataset networkkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

Vérifiez que le jeu de données est correctement défini.

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

> dataset
Network Key: 1234c0de7ab51234c0de7ab51234c0de

Affichez Thread pour que le RCP Joiner rejoigne l'atelier de programmation. réseau. Patientez quelques secondes, puis vérifiez l'état, RLOC16 et ses adresses 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

Notez l'adresse IPv6 locale du réseau maillé (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f ici), car vous en aurez besoin plus tard.

De retour sur FTD Commissioner, vérifiez le routeur et la table enfant pour vérifier que les deux appareils font partie du même réseau. Utilisez le RLOC16 pour identifier le 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

Pinguez l'adresse du maillage local de la jointure RCP (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 disposons désormais d'un réseau Thread composé de deux nœuds, illustré par ce schéma de topologie:

Diagrammes de topologie

Dans la suite de l'atelier de programmation, nous afficherons un nouveau diagramme de topologie de threads chaque fois que l'état du réseau change. Les rôles de nœud sont désignés comme suit:

Les routeurs représentent toujours des pentagones et les appareils de fin, toujours des cercles. Les numéros de chaque nœud représentent l'ID de routeur ou d'enfant affiché dans le résultat de la CLI, en fonction du rôle et de l'état actuels de chaque nœud à ce moment-là.

9. Mettre en service le FTD Joiner

Ajoutons maintenant le troisième appareil Thread à l'atelier de programmation. réseau. Cette fois, nous allons utiliser le processus de mise en service intra-bande plus sécurisé et n'autoriser que le FTD Joiner à rejoindre le groupe.

Dans FTD Joiner, obtenez le eui64 afin que le FTD Commissioner puisse l'identifier:

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

> eui64
2f57d222545271f1
Done

Dans FTD Commissioner, démarrez-le et spécifiez l'eui64 de l'appareil qui peut être joint, ainsi que l'identifiant Joiner Credential (par exemple, J01NME). L'identifiant Joiner est une chaîne spécifique à l'appareil composée de tous les caractères alphanumériques en majuscules (0-9 et A-Y, à l'exclusion des I, O, Q et Z pour la lisibilité), d'une longueur comprise entre 6 et 32 caractères.

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

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

Avertissement:Si vous obtenez une erreur lors de l'exécution de la commande commissioner joiner, arrêtez et redémarrez le rôle de commissaire avec commissioner stop et commissioner start, puis exécutez de nouveau la commande commissioner joiner.

Passez à FTD Joiner. Commencez le rôle de jointure avec l'identifiant Joiner Credential que vous venez de configurer sur FTD Commissioner:

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

> ifconfig up
Done
> joiner start J01NME
Done

Au bout d'une minute environ, vous recevez la confirmation de réussite de l'authentification:

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

>
Join success

Avertissement:Si vous attendez trop longtemps (plus de quelques minutes) avant de commencer à jouer le rôle de vedette sur FTD Joiner, il se peut que le commissaire expire et que la jointure échoue. Arrêtez et redémarrez le commissaire, puis réessayez.

Affichez Thread pour que FTD Joiner rejoigne l'atelier de programmation. et vérifiez immédiatement l'état et la 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. En effet, cet appareil n'est pas le leader et n'a pas non plus de 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, puis vérifiez le routeur et les tables enfants pour vous assurer que trois appareils existent dans "l'atelier de programmation". réseau:

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

Important:Lorsque vous vérifiez les tables du routeur et des enfants, il est possible que vous voyiez deux routeurs et un appareil final (enfant). Si c'est le cas, ne vous inquiétez pas. Vous n'avez rien fait de mal. Poursuivez la lecture pour découvrir pourquoi cela s'est produit.

Sur la base du RLOC16, le FTD Joiner s'est connecté au réseau en tant qu'appareil final (enfant). Voici notre topologie mise à jour:

10. Thread en action

Les appareils Thread de cet atelier de programmation sont un type spécifique d'appareil Full Thread (FTD) appelé "Router Éligible End Device (REED)". Cela signifie qu'ils peuvent fonctionner comme routeur ou comme appareil final et se promouvoir d'un appareil final vers un routeur.

Thread peut accepter jusqu'à 32 routeurs, mais tente de limiter le nombre de routeurs entre 16 et 23. Si un REED est associé en tant qu'appareil final (enfant) et que le nombre de routeurs est inférieur à 16, après une période aléatoire de deux minutes, il est automatiquement promu en tant que routeur.

Si vous avez 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 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

Le FTD Joiner (MAC étendu = e6cdd2d93249a243) s'est promu en routeur. Notez que le RLOC16 est différent (b800 au lieu de 0c02). En effet, le RLOC16 est basé sur l'ID de routeur et l'ID enfant d'un appareil. Lorsqu'il passe de l'appareil final au routeur, ses valeurs d'ID de routeur et d'ID enfant changent, tout comme la valeur RLOC16.

Confirmez le nouvel état et la RLOC16 sur FTD Joiner:

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

> state
router
Done
> rloc16
b800
Done

Passer à une version antérieure de FTD Joiner

Vous pouvez tester ce comportement en revenant manuellement à une version antérieure de FTD Joiner d'un routeur à un appareil final. Changez l'état en enfant et vérifiez le RLOC16:

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

> state child
Done
> rloc16
0c03
Done

De retour dans FTD Commissioner, le FTD Joiner devrait maintenant apparaître dans la table enfant (ID = 3). Il peut même se trouver 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 à un routeur avec un RLOC de b800.

Supprimer le leader

Le leader est auto-élu parmi tous les routeurs Thread. Cela signifie que si la variante optimale actuelle est supprimée du réseau Thread, l'un des autres routeurs en devient le nouveau.

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

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

> thread stop
Done
> ifconfig down
Done

En deux minutes, FTD Joiner devient le nouveau leader de thread. Vérifiez l'état et les adresses IPv6 de FTD Joiner 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. Vous remarquerez qu'il existe un nouveau RLOC16. Il s'agit du RCP Joiner, comme indiqué par son ID et son MAC étendu. Pour que le réseau Thread reste ensemble, il a changé de routeurs parents, en passant du commissaire FTD au jonctioner FTD. Cela se traduit par un nouveau RLOC16 pour la jointure RCP (car son ID de routeur est passé 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 RCP Joiner s'associe à FTD Joiner en tant qu'enfant. Vérifiez l'état et le RLOC16 pour vous assurer que:

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

> state
child
> rloc16
b801

Réassocier le commissaire FTD

Un réseau Thread à deux nœuds n'est pas très amusant. Réactivons le commissaire de FTD en ligne.

Sur FTD Commissioner, redémarrez Thread:

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

> ifconfig up
Done
> thread start
Done

Au bout de deux minutes, il se reconnecte automatiquement à "l'atelier de programmation". réseau en tant qu’Appareil final, puis s’affiche en tant que Routeur.

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

> state
router
Done

Vérifiez les tables du routeur et des enfants sur FTD Joiner 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.

"Sous deux minutes..."

Vous l'avez peut-être remarqué à plusieurs reprises au cours de l'atelier de programmation, lorsque vous attendez qu'un appareil change d'état. 120 secondes est la valeur par défaut du paramètre de réseau de threads appelé ROUTER_SELECTION_JITTER. Les appareils qui passent d'un appareil final à un routeur ou inversement retardent le changement de façon aléatoire entre 0 et ROUTER_SELECTION_JITTER (en secondes). Consultez la spécification Thread pour en savoir plus sur les paramètres du réseau Thread.

11. Dépannage

Il peut être compliqué de gérer un réseau Thread avec plusieurs appareils sur différents terminaux ou différentes fenêtres d'écran. Suivez ces conseils pour "réinitialiser" l'état du réseau ou de votre espace de travail si vous rencontrez des problèmes.

Écran

Si vous vous perdez dans votre configuration (trop de fenêtres d'écran ou d'écrans dans l'écran), continuez à fermer les fenêtres d'écran avec Ctrl+a → k jusqu'à ce qu'il n'en existe aucune et que screen -ls affiche No Sockets found sur la ligne de commande. Ensuite, recréez les fenêtres d'écran pour chaque appareil. Les états de l'appareil sont conservés même lorsque l'écran est fermé.

Nœuds de thread

Si la topologie du réseau Thread n'est pas telle que décrite dans cet atelier de programmation ou si les nœuds se déconnectent pour une raison quelconque (par exemple, parce que la machine Linux qui les alimente est mise en veille), il est préférable de désactiver Thread, d'effacer les identifiants réseau et de recommencer à partir de l'étape Créer le réseau Thread.

Pour réinitialiser les valeurs 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

12. Utiliser la multidiffusion

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 à la multidiffusion avec différents groupes d'appareils, en fonction du champ d'application.

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

Comme nous n'utilisons pas de routeur de bordure dans cet atelier de programmation, concentrons-nous sur les deux adresses de multidiffusion FTD et MED.

Lien local

Le champ d'application de liaison locale comprend toutes les interfaces Thread accessibles par une seule transmission radio ou un seul "saut". La topologie du réseau détermine quels appareils répondent à un ping envoyé à l'adresse de multidiffusion ff02::1.

Pinguez ff02::1 à partir 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 appareils dans le réseau (FTD Joiner et RCP Joiner), mais le FTD Commissioner n'a reçu qu'une seule réponse, de l'adresse de liaison locale (LLA, FTD Joiner). Cela signifie que FTD Joiner est le seul appareil auquel il peut accéder en un seul saut.

À présent, pinguez ff02::1 depuis 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

Deux réponses ! En vérifiant les adresses IPv6 des autres appareils, nous pouvons voir que le premier (qui se termine par 4b1d) est la LLA de FTD Commissioner, et que le deuxième (se terminant par 943b) est la LLA de RCP Joiner.

Cela signifie que le FTD Joiner est directement connecté à la fois au FTD Commissioner et au RCP Joiner, ce qui confirme notre topologie.

Maillage local

Le champ d'application du réseau maillé local comprend toutes les interfaces Thread accessibles au sein du même réseau Thread. Examinons les réponses à un ping envoyé à l'adresse de multidiffusion ff03::1.

Pinguez ff03::1 à partir 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-ci, le commissaire FTD a reçu deux réponses : l'une de l'outil RLOC (RLOC, se terminant par b800) et l'autre de l'EID local (ML-EID) du RCP Joiner (ML-EID, se terminant par d55f). En effet, le champ d'application du réseau maillé local représente l'ensemble du réseau Thread. Quel que soit l'endroit du réseau où se trouve un appareil, il sera abonné à l'adresse ff03::1.

Pinguez ff03::1 à partir de FTD Joiner 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 de RCP Joiner dans les deux sorties ping. Le RCP Joiner a mis beaucoup plus de temps à atteindre le FTD Commissioner (68 ms) que pour atteindre le FTD Joiner (23 ms). Cela s'explique par le fait qu'il doit effectuer deux sauts pour atteindre le commissaire FTD, au lieu d'un seul pour le joint FTD.

Vous avez peut-être également remarqué que le ping de multidiffusion local du réseau maillé répondait avec le RLOC uniquement pour les deux FTD, et non pour le Joiner RCP. 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 de RCP Joiner pour confirmer:

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

> state
child

13. Envoyer des messages avec UDP

L’un des services applicatifs fournis par OpenThread est le protocole de datagramme utilisateur (UDP), un protocole de couche de transport. Une application basée sur OpenThread pourrait utiliser l'API UDP pour transmettre des messages entre les nœuds d'un réseau Thread, ou vers d'autres appareils d'un réseau externe (comme Internet, si le réseau Thread dispose d'un routeur de bordure).

Les sockets UDP sont exposés via la CLI OpenThread. Utilisons-le pour transmettre des messages entre les deux FTD.

Obtenez l'adresse EID du réseau maillé local pour le FTD Joiner. Nous utilisons cette adresse, car elle est accessible depuis n'importe quel point du 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 associez-le à un socket pour n'importe quelle adresse IPv6:

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

> udp open
Done
> udp bind :: 1212

Basculez sur le commissaire FTD, démarrez UDP et connectez-vous au socket que vous avez configuré sur le FTD Joiner, 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 FTD Joiner, le message UDP a été reçu.

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

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

14. Félicitations !

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

Vous savez désormais:

• Différence entre les types d'appareils, les rôles et les champs d'application Thread
• comment les appareils Thread gèrent leur état au sein du réseau ;
• comment transmettre des messages simples entre les nœuds à l'aide d'UDP

Étapes suivantes

Dans la continuité de cet atelier de programmation, essayez les exercices suivants:

• Reflashez la carte FTD Joiner en tant que MTD à l'aide du binaire ot-cli-mtd et observez qu'elle ne se met jamais à niveau en routeur et qu'elle ne tente pas de devenir leader.
• Ajoutez d'autres appareils (essayez une autre plate-forme !) au réseau et esquissez la topologie à l'aide du routeur et des tables enfants, ainsi que des pings vers les adresses de multidiffusion
• Utiliser pyspinel pour contrôler le NCP
• Convertissez le NCP en routeur de bordure à l'aide du routeur de bordure OpenThread et connectez votre réseau Thread à Internet

Documentation complémentaire

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

• Plates-formes compatibles : découvrez toutes les plates-formes qui prennent en charge OpenThread.
• Build OpenThread : plus de détails sur la création et la configuration d'OpenThread
• Introduction Thread : couvre tous les concepts Thread abordés dans cet atelier de programmation

Références :

• Documentation de référence de la CLI OpenThread
• Documentation de référence de la CLI UDP OpenThread
• Documentation de référence sur le daemon OpenThread
• Documentation de référence de l'API UDP OpenThread
• Guide de référence rapide GNU Screen