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).
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.
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) |
|
Quitter la session screen | Ctrl+a → |
Créer une fenêtre dans la session screen | Ctrl+a → |
Passer d'une fenêtre à l'autre dans la même session d'écran | Ctrl+a → |
Fermer la fenêtre active de la session Écran | Ctrl+a → |
É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 → |
Diviser la fenêtre verticalement | Ctrl+a → |
Diviser la fenêtre horizontalement | Ctrl+a → |
Accéder à la fenêtre suivante | Ctrl+a → |
Déplacer la fenêtre affichée vers l'avant ou l'arrière | Ctrl+a → |
Renommer la fenêtre actuelle | Ctrl+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é à |
| Lien local | Tous les FTD et MED |
| Lien local | Tous les FTD et les routeurs de frontière |
| Réseau maillé local | Tous les FTD et MED |
| 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 :