Cette page a été traduite par l'API Cloud Translation.

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

1. Introduction

OpenThread publié par Google est une implémentation Open Source du protocole de mise en réseau Thread®. Google Nest a lancé OpenThread pour mettre la technologie utilisée dans les produits Nest à la disposition du plus grand nombre de 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 d'appareil à appareil sans fil fiable, sécurisé et à faible consommation pour les applications à domicile. OpenThread implémente toutes les couches de mise en réseau Thread, y compris IPv6, 6LoWPAN, IEEE 802.15.4 avec sécurité MAC, établissement d'un lien maillé et routage de réseau 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

Créer et faire clignoter des binaires de CLI OpenThread sur des cartes de développement
Créer un système RCP composé d'une machine Linux et d'un tableau 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 de la multidiffusion IPv6
Transmettre des messages entre des 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

Logiciel :

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 afin de 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 offre un aperçu de l'utilisation, mais vous pouvez utiliser n'importe quel autre logiciel de terminal.

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 dispositif RCP (Radio Co-Processor) Thread, et faire clignoter 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 nn52840.

Installer SEGGER J-Link

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

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 faire clignoter les binaires OpenThread sur les cartes nRF52840. Installez le build nRF5x-Command-Line-Tools-<OS> approprié sur votre machine Linux.

Placez le package extrait dans le dossier racine ~/.

Installer la chaîne d'outils GNU ARM

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

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 figurant dans le fichier readme.txt de l'archive.

Installer l'écran (facultatif)

L'écran est un outil simple permettant d'accéder aux appareils connectés via 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 permettent de vérifier 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

Daemon OpenThread:

$ script/cmake-build posix -DOT_DAEMON=ON

Vous êtes maintenant prêt à créer OpenFlash sur les cartes nRF52840.

4. Configurer l'outil d'association RCP

Compiler et flasher

Créez l'exemple OpenThread nRF52840 avec une fonctionnalité Joiner et USB native. Un appareil utilise le rôle Joiner pour être authentifié de manière sécurisée et mis en service sur un réseau Thread. Le port USB natif permet d'utiliser le CDC ACM en tant que transport série entre le nRF52840 et l'hôte.

Nettoyez d'abord le dépôt des builds précédents 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

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

$ cd ~/src/ot-nrf528xx/build/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 de la carte nRF52840, puis branchez-le à la machine Linux. Définissez l'option Source d'alimentation nRF de la carte nRF52840 sur VDD. Lorsqu'il est correctement connecté, le LED5 est activé.

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

Accédez à l'emplacement des outils de ligne de commande nRFx, puis insérez le fichier hexadécimal RCP d'OpenThread sur la carte nRF52840 à l'aide du numéro de série de la carte. Notez que si vous omettez l'option --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.

Attribuez un libellé au tableau "RCP" afin que les rôles du tableau ne soient plus perturbés.

Se connecter à un port USB natif

Étant donné que la version RCP d'OpenThread permet d'utiliser le CDC ACM USB 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 le câble micro-USB du port de débogage de la carte nRF52840 flashée, puis rebranchez-le au port micro-USB nRF USB situé à côté du bouton RESET. Définissez l'option Source d'alimentation nRF sur USB.

Démarrer le daemon OpenThread

Dans la conception RCP, utilisez le daemon OpenThread pour communiquer avec l'appareil Thread et le gérer. Commencez ot-daemon avec l'option détaillée -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 pour afficher les journaux de ot-daemon.

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 ot-daemon nœuds 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 Devices) dans la conception standard de système sur puce (SoC). En 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.

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

Compiler et flasher

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

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

Accédez au répertoire contenant la binaire de la CLI OpenThread Full Thread Device (FTD), puis 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

Branchez le câble USB au port micro USB situé à côté de la broche d'alimentation externe de la carte nRF52840, puis branchez-le à la machine Linux. Si le RCP est toujours associé à la machine Linux, cette nouvelle carte doit s'afficher en tant que port série /dev/ttyACM1 (toutes les cartes nRF52840 utilisent ttyACM pour l'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 le FTD:

Accédez à l'emplacement des outils de ligne de commande nRFx, puis insérez le fichier hexadécimal FTD de la CLI OpenThread sur la carte nRF52840 à l'aide du 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

Attribuer un libellé au "commissaire".

Se connecter à un port USB natif

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

Vérifier la compilation

Vérifiez que la compilation a bien été effectuée en accédant à la CLI OpenThread à l'aide de l'écran GNU à partir d'une fenêtre de terminal. Les cartes RF55880 utilisent un débit en bauds de 115 200.

$ screen /dev/ttyACM1 115200

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

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

Ctrl+a →

d pour vous déconnecter de l'écran FTD Commissioner et revenir au terminal Linux pour que la carte suivante puisse être flashée. Pour accéder à 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 l'outil FTD Joiner

Répétez le processus ci-dessus pour faire clignoter la troisième carte nRF52840 à l'aide du build ot-cli-ftd.hex existant. Lorsque vous avez terminé, n'oubliez pas de reconnecter la carte à l'ordinateur à l'aide du port USB nRF et de définir le bouton NRF power source (Source d'alimentation nRF) sur VDD.

Si les deux autres nœuds sont associés à la machine Linux lorsque cette troisième carte est associée, le port série /dev/ttyACM2 devrait s'afficher :

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

Ajouter un libellé au panneau "Joiner".

Lors de la vérification à l'aide de Screen, au lieu de créer une instance de Screen depuis la ligne de commande, rattachez-la à la fenêtre 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 "Écran" avec Ctrl+a → c.

Une nouvelle invite de ligne de commande apparaît. Accédez à la CLI 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 > de la CLI OpenThread. Ouvrez l'interface IPv6 et recherchez les adresses:

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

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

Ctrl+a →

d vous pouvez quitter l'écran à tout moment.

6. Configuration de la fenêtre du terminal

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

Dans l'idéal, vous devriez avoir quatre fenêtres facilement accessibles:

Service / journaux ot-daemon
RCP Joiner via ot-ctl
Commissaire FTD via la CLI OpenThread
Jointure FTD via la CLI OpenThread

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

Sur l'écran

Pour faciliter l'utilisation, démarrez une seule session screen. Vous devriez déjà en avoir un lorsque vous configurez les deux FTD.

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

Commandes d'écran de base:

Réassocier la session d'écran (depuis 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 d'écran	Ctrl+a → `n` (vers l'avant)Ctrl+a → `p` (arrière)
Fermer la fenêtre active de la session Écran	Ctrl+a → `k`

Écran partagé

L'écran vous permet de diviser le terminal en plusieurs fenêtres:

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

Si vous avez suivi l'atelier de programmation exactement, vous devriez avoir deux fenêtres (commissaire à la FTD, Joint FTD) sur la même instance de l'écran. Pour partager l'écran entre les deux, commencez par saisir votre session Écran existante:

$ screen -r

Vous devez utiliser l'un des appareils FTD. Procédez comme suit à l'écran:

Ctrl+a → S pour diviser la fenêtre horizontalement
Ctrl+a → Tab pour déplacer le curseur dans la nouvelle fenêtre vide
Ctrl+a → n pour passer à la fenêtre suivante
S'il s'agit de la même fenêtre que celle du haut, appuyez de nouveau sur Ctrl+a → n pour afficher l'autre appareil FTD.

Les deux sont visibles. Passez de l'un à l'autre en appuyant sur Ctrl+a → Tab. Nous vous recommandons 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 le joint RCP ot-ctl, ces services doivent être démarrés dans cette même instance d'écran. Pour ce faire, arrêtez ot-daemon et quittez ot-ctl, puis redémarrez-les dans de nouvelles fenêtres d'écran (Ctrl+a → c).

Cette configuration n'est pas obligatoire et est laissée à titre d'exercice pour l'utilisateur.

Utilisez les commandes suivantes pour naviguer entre les fenêtres:

Créer une fenêtre	Ctrl+a → `c`
Diviser la fenêtre verticalement	Ctrl+a →
Diviser la fenêtre horizontalement	Ctrl+a → `S`
Accéder à la fenêtre suivante	Ctrl+a → `Tab`
Déplacer la fenêtre affichée vers l'avant ou l'arrière	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 à screen -r depuis la ligne de commande.

Pour en savoir plus sur l'écran, consultez la documentation de référence GNU Screen.

7. Créer le réseau Thread

Maintenant que toutes vos fenêtres et tous vos écrans de terminal sont configurés, nous allons créer notre réseau Thread. Dans le commissaire FTD, 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 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
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 actif:

> dataset commit active
Done

Ouvrez l'interface IPv6:

> ifconfig up
Done

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

> thread start
Done

Vérifiez l'état de l'appareil au bout de quelques instants. Il devrait s'agir du leader. Obtenez également 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)

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

À partir de ot-ctl sur l'outil RCP Joiner :

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

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

À partir de la CLI OpenThread sur le FTD Joiner:

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

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

Si le réseau de l'atelier de programmation ne figure pas dans la liste, relancez l'analyse.

8. Ajouter le Joint RCP

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

Dans le document FTD Commissioner (Commissaire de la commission américaine de la fiabilité des données), nous avons noté la clé réseau, par exemple 1234c0de7ab51234c0de7ab51234c0de. Si vous devez rechercher à nouveau la clé réseau, exécutez la commande suivante sur le commissaire FTD:

## FTD Commissioner ##

> dataset networkkey
1234c0de7ab51234c0de7ab51234c0de
Done

Ensuite, dans le RCP Joiner, définissez sa clé réseau active sur la clé réseau du Commissaire FTD:

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

> dataset networkkey 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
Network Key: 1234c0de7ab51234c0de7ab51234c0de

Afficher Thread pour que le Joint RCP rejoint le réseau "&lablab". Attendez quelques secondes, 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 du réseau maillé (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f) que vous utiliserez plus tard.

Revenez au commissaire FTD, puis vérifiez que les tables des routeurs et des enfants appartiennent aux mêmes réseaux. 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

Pinguez l'adresse locale du maillage (l'adresse locale obtenue à partir de la sortie ipaddr du protocole RCP) 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 constitué de deux nœuds, illustrés par ce diagramme de topologie:

Diagrammes de topologie

Dans les autres sections de l'atelier de programmation, nous afficherons un nouveau diagramme de topologie Thread chaque fois que l'état du réseau changera. Les rôles de nœud sont indiqués comme suit:

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

9. Commissionner le Joint FTD

À présent, ajoutons le troisième appareil Thread au réseau "&lablab". Cette fois, nous allons utiliser le processus de mise en service dans la bande, plus sécurisé, et n'autoriser que l'opérateur FTD à participer.

Sur l'outil de jointure FTD, obtenez le eui64 afin que le commissaire FTD puisse l'identifier:

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

> eui64
2f57d222545271f1
Done

Dans le champ FTD Commissioner (Commissaire FTD), démarrez le Commissaire et spécifiez la eui64 de l'appareil pouvant participer à la réunion, ainsi que les identifiants Joiner, par exemple J01NME. Les identifiants de l'opérateur de jointure sont une chaîne spécifique à l'appareil de tous les caractères alphanumériques en majuscules (0-9 et A-Y, à l'exception de 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

Passez à FTD Joiner. Démarrez le rôle d'opérateur avec les identifiants de l'agent de jointure que vous venez de configurer sur le commissaire FTD:

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

> ifconfig up
Done
> joiner start J01NME
Done

Au bout d'une minute environ, vous recevez une confirmation d'authentification:

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

>
Join success

Affichez Thread pour que le Joint FTD rejoint le réseau &codetlab, puis vérifiez immédiatement l'état et 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 qu'il ne possède un rôle propre à Anycast nécessitant 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 les tables du routeur et des tables enfants pour vérifier que trois appareils existent dans le réseau &codet:

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

Sur la base de la RLOC16, l'opérateur FTD a été associé au réseau en tant qu'appareil de fin (enfant). Voici notre topologie mise à jour:

10. Fil de discussion en action

Les appareils Thread de cet atelier de programmation sont un type spécifique d'appareil Full Thread (FTD) appelé "Routeur éligible au routeur" (REED). Cela signifie qu'ils peuvent fonctionner en tant que routeur ou appareil de fin, et qu'ils peuvent passer d'un appareil de fin à un routeur.

Thread peut prendre en charge jusqu'à 32 routeurs, mais tente de maintenir un nombre de routeurs compris entre 16 et 23. Si un appareil REED est un appareil de fin (enfant) et que le nombre de routeurs est inférieur à 16, il est automatiquement promu en routeur au bout d'une période aléatoire de deux minutes.

Si vous aviez deux enfants dans votre réseau Thread après avoir ajouté l'outil 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

L'outil FTD Joiner (MAC étendu = e6cdd2d93249a243) s'est converti en routeur. Notez que RLOC16 est différent (b800 au lieu de 0c02). Cela est dû au fait que RLOC16 est basé sur l'ID de routeur et l'ID enfant d'un appareil. Lors de la transition de l'appareil de fin au routeur, les valeurs de l'ID de routeur et de l'ID enfant changent, tout comme le RLOC16.

Vérifiez le nouvel état et le RLOC16 dans le jointeur FTD :

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

> state
router
Done
> rloc16
b800
Done

Rétrograder l'opérateur FTD

Vous pouvez tester ce comportement en rétrogradant manuellement l'élément FTD Joiner d'un routeur à un appareil final. Définissez l'état sur enfant et vérifiez le RLOC16:

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

> state child
Done
> rloc16
0c03
Done

De retour dans le commissaire FTD, l'opérateur FTD doit maintenant apparaître dans la table enfant (ID = 3). Elle peut même se trouver à la fois 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 quelques instants, il repassera à un routeur avec un RLOC de b800.

Supprimer la variante optimale

Le leader est choisi par lui-même parmi tous les routeurs Thread. Cela signifie que si l'instance principale actuelle est supprimée du réseau Thread, l'un des autres routeurs deviendra le nouveau leader.

Dans le commissaire FTD, 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 du fil de discussion. Vérifiez l'état et les adresses IPv6 de l'outil d'association 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

Consultez la table enfant. Notez qu'il y a un nouveau RLOC16. Il s'agit de l'outil d'association RCP, comme indiqué par son ID et son adresse MAC étendue. Pour que le réseau Thread fonctionne de concert, il a transféré les routeurs parents du commissaire FTD au Joiner FTD. Cela entraîne une nouvelle RLOC16 pour le Joint 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 l'outil Joint RCP soit associé à l'outil Joint FTD en tant qu'enfant. Vérifiez l'état et le RLOC16 pour vérifier que:

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

> state
child
> rloc16
b801

Réassocier le commissaire de la FTD

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

Dans le commissaire FTD, redémarrez Thread:

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

> ifconfig up
Done
> thread start
Done

Au bout de deux minutes, il se reconnecte automatiquement au réseau de l'atelier de programmation en tant qu'appareil final, puis se met à jour sur un 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 comprend à nouveau trois nœuds.

11. Dépannage

Gérer un réseau Thread avec plusieurs appareils sur un terminal ou une fenêtre d'écran peut s'avérer compliqué. Suivez ces conseils pour "réinitialiser" l'état du réseau ou de votre espace de travail en cas de problème.

Écran

Si vous êtes perdu dans votre configuration (trop de fenêtres d'écran ou d'écrans d'écran), continuez de fermer les fenêtres d'écran avec Ctrl+a → k jusqu'à ce qu'il n'en existe aucune, et screen -ls sur la ligne de commande No Sockets found. Recréez ensuite les fenêtres de l'écran pour chaque appareil. Les états des appareils sont conservés même si l'écran est arrêté.

Nœuds de thread

Si la topologie du réseau Thread ne correspond pas à celle décrite dans cet atelier de programmation ou si les nœuds se déconnectent pour une raison quelconque (peut-être parce que la machine Linux qui les a mis en veille, par exemple), il est préférable de supprimer Thread, d'effacer les identifiants réseau et de recommencer à l'étape Créer le 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

12. Utiliser la multidiffusion

Multicast permet de communiquer des informations à un groupe d'appareils en même temps. Dans un réseau Thread, des adresses spécifiques sont réservées à une utilisation multicast avec différents groupes d'appareils, en fonction du champ d'application.

Adresse IPv6	Scope (Portée)	Envoyé à
`ff02::1`	Lien local	Tous les FTD et MED
`ff02::2`	Lien local	Tous les FTD et les routeurs de frontière
`ff03::1`	Réseau maillé local	Tous les FTD et MED
`ff03::2`	Réseau maillé local	Tous les FTD et les routeurs de frontière

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

Link-Local couvre toutes les interfaces Thread accessibles par une seule transmission radio ou par un seul "hop". La topologie du réseau spécifie les appareils qui répondent à un ping à l'adresse de multidiffusion ff02::1.

Pinguez ff02::1 depuis le commissaire de la 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 existe deux autres appareils sur le réseau (l'opérateur FTD et l'outil d'association RCP), mais le commissaire FTD n'a reçu qu'une réponse de la part de l'opérateur FTD Joiner Local-Link Address (LLA). Cela signifie que l'opérateur FTD est le seul appareil que le commissaire FTD peut atteindre en un seul saut.

À présent, pinguez ff02::1 à partir de l'outil 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 la première (se terminant par 4b1d) est le LLA du commissaire de la FTD, et la seconde (se terminant par 943b) est le LLA du Joint RCP.

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

Réseau maillé local

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

Pinguez ff03::1 depuis le commissaire de la 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 de la FTD a reçu deux réponses : l'une de l'outil de localisation de routage FTD Joiner (se terminant par b800) et l'autre de l'EID de regroupement local RCP (ML-EID, se terminant par d55f). C'est parce que le champ d'application local du maillage correspond à l'ensemble du réseau Thread. Quel que soit l'endroit où il se trouve sur le réseau, il sera abonné à l'adresse ff03::1.

Pinguez ff03::1 depuis l'outil 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 l'outil d'association RCP dans les deux sorties de ping. Le Joint RCP a mis beaucoup plus de temps à joindre le Commissaire à la FTD (68 ms) que pour joindre le FTD Combiné (23 ms). C'est parce qu'il doit effectuer deux sauts pour atteindre le Commissaire FTD, alors qu'un seul saut pour Joiner FTD.

Vous avez peut-être également remarqué que le ping multicast local-localisation n'a répondu au RLOC que pour les deux FTD, et non pour le Joint RCP. En effet, les FTD sont des routeurs au sein du réseau, tandis que le RCP est un appareil de fin.

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

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

> state
child

13. Envoyer des messages avec UDP

OpenThread fournit un protocole de protocole de couche de transport (UDP, User Datagram Protocol). Une application développée sur OpenThread peut 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 contient un routeur de bordure).

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

Obtenez l'adresse EID du réseau maillé pour le joint FTD. Nous utilisons cette adresse, car elle est accessible depuis n'importe quel endroit 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

Passez au commissaire FTD, démarrez UDP, puis connectez-vous au socket que vous avez configuré sur Joiner FTD à l'aide de 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. Envoyer un message du commissaire à la réglementation FTD:

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

> udp send hellothere
Done

Le message UDP a été reçu dans FTD Joiner.

## 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, rôles et champs d'application des appareils Thread
Comment les appareils Thread gèrent leurs états au sein du réseau
comment transmettre des messages simples entre les nœuds à l'aide du protocole UDP.

Étapes suivantes

En complément de cet atelier de programmation, essayez les exercices suivants:

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

Complément d'informations

Consultez openthread.io et GitHub pour diverses ressources OpenThread, y compris:

Plates-formes compatibles : découvrez toutes les plates-formes compatibles avec OpenThread.
Build OpenThread : informations supplémentaires sur la création et la configuration d'OpenThread
Thread Primer : couvre tous les concepts Thread présentés dans cet atelier de programmation

Références :