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

1. Introduction

26b7f4f6b3ea0700.png

OpenThread publié par Google est une implémentation Open Source du protocole de mise en réseau Thread®. Google Nest a lancé OpenThread pour permettre aux développeurs d'accéder à la technologie utilisée par les produits Nest 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 basse consommation 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, Mesh Link Establishment et Mailing Routing.

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.

4806d16a8c137c6d.jpeg

Points abordés

  • Créer et flasher des binaires de la CLI OpenThread sur des cartes de développement
  • Créer 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 de la multidiffusion IPv6
  • Transmettre des messages entre des nœuds Thread avec UDP

Ce dont vous avez 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 trois ports USB

Logiciel :

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

2. Premiers pas

Simulation OpenThread

Avant de commencer, nous vous conseillons de suivre l'atelier de programmation sur la simulation OpenThread afin de vous familiariser avec les concepts de base du 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. Il servira d'hôte à un appareil Thread Co-Processor (RCP) et permet de 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.

A6693D3CE213856.png

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

Téléchargez le package approprié pour votre machine, puis 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 le build approprié nRF5x-Command-Line-Tools-<OS> sur votre machine Linux.

Placer 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 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 du fichier readme.txt de l'archive.

Écran d'installation (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 l'écran, mais vous pouvez utiliser n'importe quelle application de terminal pour 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 s'assurer 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 à créer et flasher OpenThread sur les cartes nRF52840.

4. Configurer l'outil de jointure RCP

Compilation et flash

Compilez l'exemple OpenThread RFF22840 avec les fonctionnalités Joiner et USB natives. Un appareil utilise le rôle Joiner pour être authentifié de manière sécurisée et commandé sur un réseau Thread. Le port USB natif permet d'utiliser le câble USB CDC ACM comme transport série entre le nRF52840 et l'hôte.

Commencez toujours à nettoyer 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 et 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 sur la machine Linux. Définissez le commutateur source d'alimentation nRF de la carte nRF52840 sur VDD. Lorsqu'elle est correctement connectée, le LED5 est activé.

20a3b4b480356447.png

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:

c00d519ebec7e5f0.jpeg

Accédez à l'emplacement des outils de ligne de commande nRFx, puis flashez le fichier hexadécimal RCP OpenThread sur la carte nRF52840 à l'aide du numéro de série de la carte. Notez que si vous omettez l'indicateur --verify, un message d'avertissement vous indique 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 le libellé "RCP" au tableau afin de ne pas confondre ses rôles.

Se connecter en USB natif

Comme le build RCP OpenThread permet d'utiliser le port USB CDC ACM 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 USB nRF micro-USB à côté du bouton RÉINITIALISER. Définissez le paramètre Source d'alimentation nRF sur USB.

46e7b670d2464842.png

Démarrer le daemon OpenThread

Dans la conception RCP, utilisez le daemon OpenThread pour communiquer avec l'appareil Thread et le gérer. Démarrez ot-daemon avec l'indicateur détaillé -v afin de consulter 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 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 les state du nœud 2 (le nœud RCP) que vous avez démarrés 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 Thread sur la conception standard SoC. En paramètre "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 fonctionne en tant que commissaire pour authentifier et commander des appareils sur ce réseau de manière sécurisée. L'autre appareil fonctionne comme un Joiner que le Commissioner peut authentifier auprès du réseau Thread.

Compilation et flash

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 le 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 à côté de la broche d'alimentation externe de la carte nRF52840, puis branchez-le sur 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 la FTD:

c00d519ebec7e5f0.jpeg

Accédez à l'emplacement des outils de ligne de commande nRFx, puis flashez le fichier hexadécimal FTD d'OpenThread CLI 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

Ajoutez le libellé "Commissaire" au tableau.

Se connecter en USB natif

Comme le build OpenThread FTD permet d'utiliser le format ADC USB ACM 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 USB nRF micro-USB à côté du bouton RÉINITIALISER. Définissez le paramètre Source d'alimentation nRF sur USB.

46e7b670d2464842.png

Vérifier le build

Vérifiez la compilation en accédant à la CLI OpenThread à l'aide de GNU Screen à partir d'une fenêtre de terminal. Les cartes nRF52840 utilisent un taux de 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. Affichez l'interface IPv6 et recherchez les adresses:

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

Ctrl+a →

d pour se déconnecter de l'écran de la CLI FTD Commissioner et revenir au terminal Linux afin que la carte suivante puisse être flashée. Pour saisir à 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 flasher la troisième carte nRF52840, à l'aide du build ot-cli-ftd.hex existant. Une fois cette opération terminée, assurez-vous de reconnecter la carte à l'ordinateur à l'aide du port USB nRF et de définir le commutateur 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 doit se présenter:

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

Ajoutez le libellé "Joiner" au tableau.

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 VM existante et créez-en une autre (que vous avez utilisée pour le commissaire de FTD):

$ screen -r

Créez une fenêtre dans Écran à l'aide du raccourci Ctrl+a → c.

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

$ 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. Affichez 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 dans la même instance d'écran que la FTD Commissaire, vous pouvez passer de l'une à l'autre en appuyant sur Ctrl+a → n.

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 accessibles et facilement accessibles. Jusqu'à présent, nous utilisions l'écran pour accéder aux deux FTD. Cet outil permet également d'utiliser l'écran partagé sur la même fenêtre de terminal. Il vous permet de voir comment un nœud réagit aux commandes émises sur un autre.

Dans l'idéal, quatre fenêtres devraient être disponibles:

  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

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.

Utiliser l'écran

Pour faciliter l'utilisation, démarrez une seule session Screen. Vous devriez en avoir un lorsque vous avez configuré les deux FTD.

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

Commandes d'écran de base:

Réassocier la session à l'écran (à partir de la ligne de commande)

screen -r

Quitter la session Écran

Ctrl+a → d

Créer une fenêtre dans la session d'écran

Ctrl+a → c

Changer de fenêtre dans la même session d'écran

Ctrl+a → n (avancer) Ctrl+a → p (retour)

Fermer la fenêtre active dans la session Écran

Ctrl+a → k

Écran partagé

Il vous permet de scinder le terminal en plusieurs fenêtres:

f1cbf1258cf0a5a.png

Pour accéder aux commandes de screen, appuyez sur Ctrl+a. Chaque commande doit commencer par cette combinaison de clés d'accès.

Si vous avez suivi exactement l'atelier de programmation, vous devez avoir deux fenêtres (commissaire au FTD, FTD Joiner) sur la même instance d'écran. Pour diviser l'écran entre les deux, accédez d'abord à votre session d'écran existante:

$ screen -r

Vous devez utiliser l'un des appareils FTD. Procédez comme suit à 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 fenêtre suivante
  4. S'il est identique à la fenêtre supérieure, appuyez de nouveau sur Ctrl+a → n pour afficher l'autre appareil FTD.

Les deux sont maintenant visibles. Passez de l'un à l'autre via 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, vous devez démarrer ces services dans cette même instance d'écran. Pour ce faire, arrêtez ot-daemon et quittez ot-ctl, puis redémarrez-le dans les nouvelles fenêtres d'écran (Ctrl+a → c).

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

Divisez les fenêtres et naviguez entre elles à l'aide des commandes suivantes:

Créer une fenêtre

Ctrl+a → c

Fractionner la fenêtre verticalement

Ctrl+a →

Fractionner la fenêtre horizontalement

Ctrl+a → S

Passer à la fenêtre suivante

Ctrl+a → Tab

Déplacer la fenêtre affichée vers l'avant ou vers l'arrière

Ctrl+a → n ou p

Renommer la fenêtre active

Ctrl+a → A

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

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

7. Créer le réseau Thread

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

> dataset commit active
Done

Affichez l'interface IPv6:

> ifconfig up
Done

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

> thread start
Done

Après quelques instants, vérifiez l'état de l'appareil. 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 "codelab" est désormais visible lorsqu'il est analysé à partir d'autres appareils Thread.

Depuis ot-ctl sur l'outil de jointure RRC:

## 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 "codelab" n'apparaît pas dans la liste, réessayez de lancer l'analyse.

8. Ajouter le Joint RCP

La mise en service Thread n'est pas active sur le réseau. Par conséquent, 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.

Sur le commissaire à la FTD, 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 l'outil RCP Joiner, définissez la clé réseau de son ensemble de données actif sur la clé réseau du commissaire de la FTD:

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

> dataset networkkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

Vérifiez que l'ensemble de données est correctement défini.

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

> dataset
Network Key: 1234c0de7ab51234c0de7ab51234c0de

Affichez Thread pour que le Joint RCP rejoint le réseau "atelier de programmation". Attendez 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 maillage (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f). Vous en aurez besoin plus tard.

Sur le commissaire au FTD, vérifiez le routeur et les tables enfants pour vous assurer que les deux appareils appartiennent au 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

Pinguez l'adresse locale du maillage RCP (l'adresse locale obtenue à partir de la sortie ipaddr du joint 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 à présent d'un réseau Thread composé de deux nœuds, illustrés par ce schéma de topologie:

otcodelab_top01C_2nodes.png

Diagrammes de topologie

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

B75A527be4563215.png

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

9. Commissionner l'agent FTD

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

Dans l'outil de jointure FTD, récupérez le eui64, afin que le commissaire FTD puisse l'identifier:

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

> eui64
2f57d222545271f1
Done

Dans le commissaire à la FTD, démarrez le commissaire et spécifiez la eui64 de l'appareil pouvant participer, ainsi que les identifiants du membre de l'association, par exemple J01NME. L'identifiant de jointure est 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é), comprenant 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 de collaborateur avec les identifiants Joiner que vous venez de configurer sur le commissaire à la 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 "atelier de programmation", et 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. Cela s'explique par le fait que cet appareil n'en est pas un leader et qu'il ne dispose pas d'un rôle spécifique à Anycast qui nécessite une 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)

Basculez immédiatement vers le commissaire au FTD et vérifiez les tables du routeur et des enfants pour vérifier que le réseau "atelier de programmation" compte trois appareils:

## 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 la RLOC16, l'outil FTD Joiner s'est connecté au réseau en tant qu'appareil final (enfant). Voici notre topologie mise à jour:

otcodelab_top01C_ed01.png

10. Fil de discussion en action

Les appareils Thread de cet atelier de programmation sont un type spécifique d'appareil Thread complet appelé "appareil de fin éligible au routeur" (REED). Cela signifie qu'ils peuvent servir de routeur ou d'appareil de fin et peuvent être promus d'un appareil final à un routeur.

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

Si vous avez eu deux enfants sur 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 à la 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 promu à un routeur. Notez que RLOC16 est différent (b800 au lieu de 0c02), car il est basé sur l'ID de routeur et l'ID enfant d'un appareil. Lorsqu'il passe d'un appareil final à un routeur, les valeurs de son ID de routeur et de son ID enfant changent, tout comme le RLOC16.

otcodelab_top01C.png

Vérifiez le nouvel état et le RLOC16 dans l'outil FTD Joiner:

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

> state
router
Done
> rloc16
b800
Done

Revenir à la version standard de FTD Joiner

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

otcodelab_top01C_ed02.png

De retour sur le commissaire à la FTD, l'opérateur FTD devrait maintenant apparaître dans la table enfant (ID = 3). Elle peut même se trouver pendant les transitions:

## 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 revient à un routeur avec un RLOC b800.

otcodelab_top01C.png

Supprimer la variante optimale

Le leader est choisi par tous les routeurs Thread. Cela signifie que si le responsable actuel est supprimé du réseau Thread, l'un des autres routeurs devient le leader.

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

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

> thread stop
Done
> ifconfig down
Done

En l'espace de deux minutes, FTD Joiner devient le nouveau leader des threads. 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

otcodelab_top02C_01.png

Vérifiez la table enfant. Notez qu'il existe un nouveau RLOC16. Il s'agit de l'outil de liaison RCP, comme indiqué par son ID et son adresse MAC étendue. Pour maintenir le réseau Thread ensemble, il a basculé les routeurs parents du commissaire de la FTD vers le FTD Joiner. 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 que l'association RRC soit jointe à l'outil FTD Joiner 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 à la réglementation de la FTD

Ce n'est pas très amusant de pouvoir utiliser un réseau Thread avec deux nœuds. Mettons le FTD Commissioner en ligne.

Sur le commissaire à la FTD, redémarrez Thread:

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

> ifconfig up
Done
> thread start
Done

En deux minutes, il se rattache automatiquement au réseau "codelab" en tant qu'appareil final, puis se met à disposition sur un routeur.

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

> state
router
Done

Vérifiez les tables du routeur et des enfants sur FTD Joiner pour vérifier que:

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

otcodelab_top02C_02.png

Notre réseau Thread comprend à nouveau trois nœuds.

PCI 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 si vous rencontrez des problèmes.

Écran

Si vous vous retrouvez perdu dans votre configuration (trop de fenêtres ou plusieurs écrans s'affichent), continuez à fermer les fenêtres de l'écran en appuyant sur Ctrl+a → k jusqu'à ce qu'il n'en existe pas et en appuyant sur screen -ls sur la ligne de commande pour générer No Sockets found. Ensuite, recréez les fenêtres de l'écran pour chaque appareil. Les états de l'appareil sont conservés même lorsque 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 les mettant en veille), 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 le FTD:

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

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

Vous pouvez réinitialiser le RCP 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 une seule fois. Dans un réseau Thread, des adresses spécifiques sont réservées à l'utilisation de la multidiffusion avec différents groupes d'appareils, en fonction du champ d'application.

Adresse IPv6

Scope (Portée)

Livraison à

ff02::1

Lien local

Tous les FTD et les MED

ff02::2

Lien local

FTD et routeurs de bordure

ff03::1

Maillage local

Tous les FTD et les MED

ff03::2

Maillage local

FTD et 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.

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

Pinguez ff02::1 depuis le FTD Commissioner:

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

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

Deux autres appareils sont présents sur le réseau (FTD Joiner et RCP Joiner), mais le FTD Commissioner n'a reçu qu'une seule réponse de la part de FTD Joiner's Local-Local Address (LLA). Cela signifie que le FTD Joiner est le seul appareil que le commissaire FTD peut atteindre en un seul saut.

otcodelab_top02C_02_LL.png

À présent, pinguez ff02::1 à partir de l'outil de jointure 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 examinant les adresses IPv6 des autres appareils, nous pouvons voir que le premier (se terminant par 4b1d) est le LLA du FTD Commissioner, et le second (se terminant par 943b) est le LLA du RCP Joiner.

otcodelab_top02C_02_LL02.png

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

Maillage local

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

Pinguez ff03::1 depuis le FTD Commissioner:

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

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

Cette fois, le commissaire de la FTD a reçu deux réponses : une de l'outil de localisation de routage de la liaison FTD (RLOC, se terminant par b800) et l'autre de l'EID maillé local du RCP (ML-EID, se terminant par d55f). Cela est dû au fait que le champ d'application du maillage maillé local couvre l'ensemble du réseau Thread. Peu importe où se trouve l'appareil sur le réseau, il est abonné à l'adresse ff03::1.

otcodelab_top02C_02_ML.png

Pinguez ff03::1 à partir de l'outil de jointure 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

otcodelab_top02C_02_LL02.png

Notez le temps de réponse de l'outil de jointure RCP dans les deux sorties de ping. L'association RCP a mis beaucoup plus de temps à joindre le commissaire à la FTD (68 ms) que 23 ms. Cela s'explique par le fait que deux sauts doivent être nécessaires pour atteindre le commissaire à la FTD, alors qu'un seul bond a été sauté pour l'opérateur FTD.

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

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

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

> state
child

13. Envoyer des messages avec le protocole UDP

L'un des services d'application fournis par OpenThread est le protocole UDP (User Datagram Protocol), un protocole de couche de transport. Une application créée sur OpenThread peut utiliser l'API UDP pour transmettre des messages entre des nœuds d'un réseau Thread, ou vers d'autres appareils dans 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 locale du maillage 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 toute adresse IPv6:

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

> udp open
Done
> udp bind :: 1212

Passez à FTD Commissioner (Commissaire FTD), démarrez UDP, puis connectez-vous au socket que vous avez configuré sur le FTD Joiner à 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 Commissioner FTD:

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

> udp send hellothere
Done

Le message UDP a été reçu sur 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.

B915C433E7027cc7.png

Vous savez désormais:

  • Différence entre les types d'appareils, les rôles et les habilitations 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 de l'UDP

Étapes suivantes

En vous appuyant sur cet atelier de programmation, effectuez les exercices suivants:

  • Flashez la carte FTD Joiner en tant que MTD à l'aide du binaire ot-cli-mtd. Notez qu'elle ne se met jamais à niveau ou ne devient jamais leader.
  • Ajoutez d'autres appareils (essayez une autre plate-forme !) au réseau et esquissez la topologie en utilisant des tables de routeur et d'enfant, ainsi que des pings aux adresses de multidiffusion.
  • Utiliser le pyspinel pour contrôler le NCP
  • Convertissez le NCP en routeur de bordure à l'aide d'OpenBorder Border Router et connectez votre réseau Thread à Internet.

Documentation complémentaire

Rendez-vous sur openthread.io et GitHub pour accéder à 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 Prime : couvre tous les concepts de Thread présentés dans cet atelier de programmation.

Références :