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 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.
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.
Installer SEGGER J-Link
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é.
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 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.
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:
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.
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:
- Service / Journaux
ot-daemon
- RCP Joiner via
ot-ctl
- FTD Commissioner via la CLI OpenThread
- 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) |
|
Quitter la session Écran | Ctrl+a → |
Créer une fenêtre dans la session d'écran | Ctrl+a → |
Changer de fenêtre dans la même session d'écran | Ctrl+a → |
Fermer la fenêtre active dans la session Écran | Ctrl+a → |
Écran partagé
Il vous permet de scinder le terminal en plusieurs fenêtres:
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:
- 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 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 → |
Fractionner la fenêtre verticalement | Ctrl+a → |
Fractionner la fenêtre horizontalement | Ctrl+a → |
Passer à la fenêtre suivante | Ctrl+a → |
Déplacer la fenêtre affichée vers l'avant ou vers l'arrière | Ctrl+a → |
Renommer la fenêtre active | Ctrl+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:
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:
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:
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.
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
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
.
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
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
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 à |
| Lien local | Tous les FTD et les MED |
| Lien local | FTD et routeurs de bordure |
| Maillage local | Tous les FTD et les MED |
| 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.
Lien local
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.
À 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.
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
.
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
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.
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 :