1. Présentation
OpenThread publié par Google est une mise en œuvre Open Source du protocole réseau Thread®. Google Nest a lancé OpenThread pour rendre la technologie utilisée dans les produits Nest accessible à tous les développeurs, afin d'accélérer le développement de produits pour la maison connectée.
La spécification Thread définit un protocole de communication sans fil entre appareils fiable et sécurisé, basé sur IPv6, pour les applications domestiques. OpenThread met en œuvre toutes les couches réseau Thread, y compris IPv6, 6LoWPAN et IEEE 802.15.4 avec sécurité MAC, maillage de liens et routage du maillage.
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.
Ce que vous allez apprendre
- Créer des binaires de CLI OpenThread et faire clignoter 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 plusieurs nœuds Thread avec UDP
Prérequis
Matériel:
- 3 cartes de développement nordic Semiconductor nRF52840
- Câbles USB vers micro USB pour connecter les cartes
- Une machine Linux avec au moins trois ports USB
Logiciels :
- GNU Toolchain
- Outils de ligne de commande Nordic NRF5x
- Logiciel Segger J-Link
- OpenThread
- Git
2. Premiers pas
Simulation OpenThread
Avant de commencer, nous vous recommandons de suivre cet atelier de programmation pour vous familiariser avec les concepts de base de Thread et avec la CLI OpenThread.
Bornes de port série
Vous devez savoir comment vous connecter à un port série via un terminal. Cet atelier de programmation utilise GNU Screen et fournit une présentation de l'utilisation, mais tout autre logiciel de terminal peut être utilisé.
Machine Linux
Cet atelier de programmation a été conçu pour utiliser une machine Linux basée sur le format i386 ou x86 afin d'héberger un appareil Thread co-processeur (RCP) et de 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 nordique semi-conducteur 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-la sur votre ordinateur Linux.
Téléchargez le package adapté à votre ordinateur, puis installez-le à l'emplacement approprié. 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 transférer les fichiers binaires OpenThread vers les cartes nRF52840. Installez la version nRF5x-Command-Line-Tools-<OS> appropriée sur votre ordinateur Linux.
Placez le package extrait dans le dossier racine ~/
.
Installer ARM GNU Toolchain
La chaîne d'outils ARM GNU est utilisée pour la création.
Nous vous recommandons de placer l'archive extraite dans /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/
sur votre ordinateur Linux. Suivez les instructions d'installation du fichier readme.txt
de l'archive.
Installer l'écran (facultatif)
L'écran est un outil simple pour accéder aux appareils connectés via un port série. Cet atelier de programmation utilise le filtrage d'écran, mais vous pouvez utiliser n'importe quelle application de terminal de port série.
$ sudo apt-get install screen
3. Cloner les dépôts
OpenThread
Clonez et installez OpenThread. Les commandes script/bootstrap
garantissent que la chaîne d'outils est installée et que l'environnement est correctement configuré:
$ mkdir -p ~/src $ cd ~/src $ git clone --recursive https://github.com/openthread/openthread.git $ cd openthread $ ./script/bootstrap
Créez le daemon OpenThread:
$ script/cmake-build posix -DOT_DAEMON=ON
Vous êtes maintenant prêt à compiler et ouvrir Flash aux cartes nRF52840.
4. Configurer le jointur RCP
Build et flash
Créez l'exemple OpenThread nRF52840 avec Joiner et la fonctionnalité USB native. Un appareil utilise le rôle de jointure pour s'authentifier de manière sécurisée et être mis en service sur un réseau Thread. L'utilisation de l'USB natif permet d'utiliser l'interface ADC ACM d'USB comme transport série entre le nRF52840 et l'hôte.
Commencez toujours par 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
Connectez le câble USB au port de débogage micro USB situé à côté de la broche d'alimentation externe de la carte nRF52840, puis branchez-le à la machine Linux. Définissez le bouton Source d'alimentation nRF sur la carte nRF52840 sur VDD. Lorsque la LED 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
comme identifiant de port série).
$ ls /dev/ttyACM* /dev/ttyACM0
Notez le numéro de série de la carte nRF52840 utilisée pour le RCP:
Accédez à l'emplacement des outils de ligne de commande nRFx, puis flashez le fichier hexadécimal RCP OpenThread sur la carte nRF52840, en utilisant le numéro de série de la carte. Notez que si vous omettez l'option --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.
Ajoutez le libellé "RCP" au tableau afin de ne pas confondre ses rôles.
Se connecter à un port USB natif
Étant donné que la compilation RCP OpenThread permet d'utiliser la norme ACM ADC native 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 clignote, puis rebranchez-la sur le port micro USB nRF à côté du bouton RÉINITIALISER. (Installation de Python groupée). Définissez le bouton 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'indicateur détaillé -v
afin de pouvoir afficher la sortie du journal et vérifier qu'elle est en cours d'exécution:
$ cd ~/src/openthread $ ./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 une sortie semblable à celle-ci:
ot-daemon[228024]: Running OPENTHREAD/20191113-00831-gfb399104; POSIX; Jun 7 2020 18:05:15 ot-daemon[228024]: Thread version: 2 ot-daemon[228024]: RCP version: OPENTHREAD/20191113-00831-gfb399104; SIMULATION; Jun 7 2020 18:06:08
Laissez cette fenêtre de terminal ouverte afin que les journaux de ot-daemon
puissent être affiché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
:
$ ./build/posix/bin/ot-ctl >
Vérifiez le state
du nœud 2 (le nœud RCP) que vous avez commencé avec ot-daemon
:
> state disabled Done
5. Configurer les FTD
Les deux autres nœuds Thread utilisés dans cet atelier de programmation sont les fils complets (FTD) de la conception standard System-on-Chip (SoC). Dans un environnement de production, vous pouvez utiliser wpantund
, un pilote d'interface réseau de production, pour contrôler les instances NCP OpenThread, mais dans cet atelier de programmation, nous utiliserons ot-ctl
, le thread CLI
Le premier est le Commissaire, qui assure l'authentification et la mise en service sécurisées des appareils sur le réseau. L'autre appareil fonctionne comme un jointur qui peut s'authentifier auprès du réseau Thread.
Build et flash
Créez l'exemple FTD OpenThread pour la plate-forme nRF52840, avec les rôles de commissaire et de jointure activés:
$ cd ~/src/ot-nrf528xx $ rm -rf build $ script/build nrf52840 USB_trans -DOT_JOINER=ON -DOT_COMMISSIONER=ON
Accédez au répertoire contenant le binaire CLI FTD (OpenThread Full Thread Device) et convertissez-le au format hexadécimal:
$ cd ~/src/ot-nrf528xx/build/bin $ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex
Branchez le câble USB sur le port micro USB situé à côté de la broche d'alimentation externe de la carte nRF52840, puis branchez-le sur la machine Linux. Si le RCP est toujours associé à la machine Linux, ce nouveau tableau doit apparaître comme port série /dev/ttyACM1
(toutes les cartes nRF52840 utilisent ttyACM
comme identifiant de port série).
$ ls /dev/ttyACM* /dev/ttyACM0 /dev/ttyACM1
Comme précédemment, notez le numéro de série de la carte nRF52840 utilisée pour le flux FTD:
Accédez à l'emplacement des outils de ligne de commande nRFx, puis flashez le fichier hexadécimal FTD de la CLI OpenThread sur la carte nRF52840, en utilisant le numéro de série de la carte:
$ cd ~/nrfjprog/ $ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \ ~/src/ot-nrf528xx/build/bin/ot-cli-ftd.hex --reset
Ajoutez un libellé "Commissaire" au tableau.
Se connecter à un port USB natif
Étant donné que le build FTD d'OpenThread permet l'utilisation de la clé USB CDC ACM native 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 clignote, puis rebranchez-la sur le port micro USB nRF à côté du bouton RÉINITIALISER. (Installation de Python groupée). Définissez le bouton Source d'alimentation nRF sur USB.
Vérifier le build
Vérifiez que la compilation est réussie en accédant à la CLI OpenThread à l'aide de GNU Screen à partir d'une fenêtre de terminal. Les cartes nRF52840 utilisent un débit en bauds de 115 200.
$ screen /dev/ttyACM1 115200
Dans la nouvelle fenêtre, appuyez plusieurs fois sur la touche Retour du clavier pour afficher l'invite de la CLI OpenThread >
. Affichez l'interface IPv6 et vérifiez les adresses:
> ifconfig up Done > ipaddr fe80:0:0:0:1cd6:87a9:cb9d:4b1d Done
Ctrl+a→
d
pour le dissocier de l'écran de la CLI du commissaire FTD et revenir au terminal Linux pour que le tableau suivant puisse clignoter. Pour accéder de nouveau à la CLI à tout moment, utilisez screen -r
à partir de la ligne de commande. Pour afficher la liste des écrans disponibles, utilisez la commande screen -ls
:
$ screen -ls There is a screen on: 74182.ttys000.mylinuxmachine (Detached) 1 Socket in /tmp/uscreens/S-username.
Configurer le jointur FTD
Répétez le processus ci-dessus pour faire clignoter le troisième tableau nRF52840 à l'aide de la version ot-cli-ftd.hex
existante. Lorsque vous avez terminé, reconnectez le tableau au PC à l'aide du port USB nRF et définissez le bouton Source d'alimentation nRF sur VDD.
Si les deux autres nœuds sont associés à la machine Linux lorsque ce troisième tableau est connecté, il doit apparaître comme port série /dev/ttyACM2
:
$ ls /dev/ttyACM* /dev/ttyACM0 /dev/ttyACM1 /dev/ttyACM2
Ajoutez le libellé "Jointeur" au tableau.
Lorsque vous effectuez la validation à l'aide de l'écran, au lieu de créer une instance d'écran à partir de la ligne de commande, réassociez-la à la fenêtre existante et créez une nouvelle fenêtre (que vous avez utilisée pour le Commissaire FTD):
$ screen -r
Créez une fenêtre à l'écran en appuyant sur 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 >
. Affichez l'interface IPv6 et vérifiez les adresses:
> ifconfig up Done > ipaddr fe80:0:0:0:6c1e:87a2:df05:c240 Done
Maintenant que la CLI de l'opérateur FTD se trouve dans la même instance de Screen que le commissaire FTD, vous pouvez passer de l'un à l'autre en appuyant sur Ctrl+a → n
.
Ctrl+a→
d
à tout moment pour quitter l'écran.
6. Configuration des fenêtres de terminal
À l'avenir, vous basculerez fréquemment d'un appareil Thread à l'autre. Vérifiez donc que tous ces appareils sont actifs et facilement accessibles. Jusqu'à présent, nous utilisons l'écran pour accéder aux deux flux de données. Cet outil permet aussi d'utiliser l'écran partagé dans la même fenêtre de terminal. Utilisez-la pour 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
Si vous souhaitez utiliser votre propre configuration de terminal ou de port série, vous pouvez passer à l'étape suivante. Configurez les fenêtres de terminal de tous les appareils en fonction de vos besoins.
Utiliser l'écran
Pour plus de simplicité, ne démarrez qu'une session de visionnage. Vous devez en avoir une une lors de la configuration des deux périodes de suivi.
Toutes les commandes de l'écran commencent par Ctrl+a.
Commandes de base de l'écran:
Réintégrer une session à l'écran (à partir de 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 Screen | Ctrl+a → |
Fermer la fenêtre active dans la session "Écran" | Ctrl+a → |
Écran partagé
Avec la fonctionnalité Écran, vous pouvez diviser le terminal en plusieurs fenêtres:
Les commandes de screen
sont accessibles à l'aide de 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 devriez avoir deux fenêtres (FTD Commissaire, FTD Joiner) sur la même instance Screen. Pour partager l'écran entre les deux, saisissez d'abord votre session Écran existante:
$ screen -r
Vous devez utiliser l'un des appareils FTD. Procédez comme suit dans 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 nouvelle fenêtre - Si c'est le cas, appuyez à nouveau sur Ctrl+a →
n
pour afficher l'autre appareil FTD.
Les deux sont désormais visibles. Passez de l'un à l'autre à l'aide de Ctrl+a → Tab
. Nous vous recommandons de modifier le nom de chaque fenêtre avec Ctrl+a → A
pour éviter toute confusion.
Utilisation avancée
Pour fractionner davantage l'écran en quadrant et afficher les journaux ot-daemon
et le jointeur RCP ot-ctl
, ces services doivent être démarrés dans cette même instance Screen. 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 fait l'objet d'exercices pour l'utilisateur.
Fractionnez et passez d'une fenêtre à l'autre à l'aide des commandes suivantes:
Créer une fenêtre | Ctrl+a → |
Scinder la fenêtre verticalement | Ctrl+a → |
Scinder la fenêtre horizontalement | Ctrl+a → |
Accéder à la fenêtre affichée suivante | Ctrl+a → |
Avancer ou revenir en arrière dans la fenêtre affichée | 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 le guide de référence sur l'écran GNU.
7. Créer le réseau Thread
Maintenant que tous les écrans et toutes vos fenêtres de terminal sont configurés, nous allons créer notre réseau Thread. Dans le cadre du commissaire FTD, créez un nouvel ensemble de données opérationnelles et validez-le en tant qu'ensemble actif. L'ensemble de données opérationnel correspond à 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 vous servira plus tard.
Validez cet ensemble de données en tant qu'ensemble actif:
> dataset commit active Done
Affichez l'interface IPv6:
> ifconfig up Done
Démarrez l'opération associée au protocole Thread:
> thread start Done
Vérifiez l'état de l'appareil après quelques instants. Il doit 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 "atelier de programmation" est désormais visible lorsqu'il est analysé depuis d'autres appareils Thread.
Dans ot-ctl
sur le membre PRC:
## RCP Joiner ## ---------------- > scan | J | Network Name | Extended PAN | PAN | MAC Address | Ch | dBm | LQI | +---+------------------+------------------+------+------------------+----+-----+-----+ | 0 | OpenThread-c0de | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |
Depuis la CLI OpenThread sur FTD Joiner:
## FTD Joiner ## ---------------- > scan | J | Network Name | Extended PAN | PAN | MAC Address | Ch | dBm | LQI | +---+------------------+------------------+------+------------------+----+-----+-----+ | 0 | OpenThread-c0de | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |
Si le réseau "atelier de programmation" n'apparaît pas dans la liste, relancez la recherche.
Vous remarquerez peut-être que dans les deux analyses, le réseau ne semble pas joignable (colonne J sur le jointeur RCP et jointure FTD). Cela signifie simplement que la mise en service Thread n'est pas active sur le réseau. Vous pouvez toujours l'utiliser hors bande, en saisissant manuellement la clé réseau dans l'appareil associé.
8. Ajouter le jointeur RCP
Ajoutons le Jointeur RCP au réseau Thread que nous venons de créer en utilisant un processus hors bande. Recherchez des réseaux sur le RCP Joiner:
## RCP Joiner ## ---------------- > scan | J | Network Name | Extended PAN | PAN | MAC Address | Ch | dBm | LQI | +---+------------------+------------------+------+------------------+----+-----+-----+ | 0 | OpenThread-c0de | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |
Pour rejoindre la réunion, définissez la clé réseau (que nous venons d'obtenir auprès du commissaire FTD) sur le Joint RCP dans son ensemble de données actif.
## 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 RCP Joiner rejoint le réseau "atelier de programmation". Attendez quelques secondes, puis vérifiez l'état, Rloc16 et ses adresses IPv6:
## RCP Joiner ## ---------------- > 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é local (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f
ici). Vous l'utiliserez plus tard.
Revenez au commissaire de FTD, et vérifiez que les tables du routeur et des enfants sont bien connectées au même réseau. Utilisez le protocole Rloc16 pour identifier le jointure 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 du réseau maillé local de l'opérateur RCP (l'adresse locale obtenue à partir de la sortie ipaddr
de l'opérateur 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 avons maintenant un réseau Thread composé de deux nœuds, illustré par ce diagramme de topologie:
Diagrammes de topologie
Tout au long de l'atelier de programmation, nous afficherons un nouveau schéma de topologie Thread à chaque changement d'état du réseau. Les rôles de nœud sont décrits comme suit:
Les routeurs sont toujours des pentagones, et les appareils finaux sont toujours des cercles. Les chiffres figurant sur chaque nœud représentent l'ID du routeur ou l'ID enfant affiché dans la sortie de la CLI, en fonction du rôle et de l'état actuels de chaque nœud à ce moment-là.
9. Rejoindre le programme FTD
Ajoutons à présent le troisième appareil Thread au réseau "atelier de programmation". Cette fois, nous allons utiliser le processus de mise en service intrabande plus sécurisé. Dans le champ FTD Joiner, recherchez le réseau:
## FTD Joiner ## ---------------- > scan | J | Network Name | Extended PAN | PAN | MAC Address | Ch | dBm | LQI | +---+------------------+------------------+------+------------------+----+-----+-----+ | 0 | OpenThread-c0de | c0de7ab5c0de7ab5 | c0de | f65ae2853ff0c4e4 | 11 | -36 | 57 |
Un 0
dans la colonne J indique que la mise en service Thread n'est pas active sur l'appareil.
Soyez précis lors de la mise en service sur cet appareil suivant et n'autorisons que le membre du programme FTD à rejoindre le programme. Toujours sur le compte du FTD, obtenez le eui64
pour que le commissaire puisse l'identifier:
## FTD Joiner ## ---------------- > eui64 2f57d222545271f1 Done
Dans la section Commission FTD, démarrez le commissaire et spécifiez le type d'appareil eui64
qui peut être associé, ainsi que les identifiants de jointure (par exemple, J01NME
). L'identifiant de jointure est une chaîne spécifique à l'appareil qui comprend tous les caractères alphanumériques en majuscules (0 à 9 et AY, à l'exclusion des points I, O, Q et Z) pour une facilité de lecture comprise entre 6 et 32 caractères.
## FTD Commissioner ## ---------------------- > commissioner start Done > commissioner joiner add 2f57d222545271f1 J01NME Done
Passez à FTD Joiner, puis relancez la recherche:
## FTD Joiner ## ---------------- > scan | J | Network Name | Extended PAN | PAN | MAC Address | Ch | dBm | LQI | +---+------------------+------------------+------+------------------+----+-----+-----+ | 1 | OpenThread-c0de | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -45 | 196 |
Comme indiqué par 1
dans la colonne J, la mise en service Thread est désormais active sur le réseau. Lancez le rôle de jointure avec les identifiants de jointure que vous venez de configurer dans le Commissaire FTD:
## FTD Joiner ## ---------------- > ifconfig up Done > joiner start J01NME Done
Dans la minute qui suit, vous recevez la confirmation d'une authentification réussie:
## FTD Joiner ## ---------------- > Join success
Ouvrez Thread pour que le Jointure FTD rejoint le réseau de l'atelier de programmation, puis vérifiez immédiatement l'état et RTL16:
## 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'ALO. En effet, cet appareil n'est pas le leader et ne dispose pas d'un rôle Anycast qui nécessite un ATL.
## FTD Joiner ## ---------------- > ipaddr fdc0:de7a:b5c0:0:0:ff:fe00:c02 # Routing Locator (RLOC) fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd # Mesh-Local EID (ML-EID) fe80:0:0:0:e4cd:d2d9:3249:a243 # Link-Local Address (LLA)
Passez immédiatement au commissaire FTD, puis vérifiez le routeur et les tables enfants pour vérifier que trois appareils existent dans le réseau "atelier de programmation" :
## 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
D'après le RTL16, le jointeur FTD a rattaché le réseau en tant qu'appareil de fin (enfant). Voici notre nouvelle topologie:
10. Fil de discussion en action
Les appareils Thread de cet atelier de programmation sont un type spécifique d'appareil à thread complet (FTD, Router Éligible Device Device, appareil fin de réseau éligible). Cela signifie qu'ils peuvent fonctionner comme routeurs ou appareils finaux. Ils peuvent aussi être utilisés pour la promotion d'un appareil final vers un routeur.
Thread peut prendre en charge jusqu'à 32 routeurs, mais tente de maintenir le nombre de routeurs entre 16 et 23. Si un REED est associé en tant qu'appareil de fin (enfant) et que le nombre de routeurs est inférieur à 16, après une période aléatoire de deux minutes, il passe automatiquement en routeur.
Si votre réseau Thread comportait deux enfants après avoir ajouté le jointeur FTD, attendez au moins deux minutes, puis revérifiez le routeur et les tables enfants sur le commissaire aux États-Unis:
## 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
FTD Joiner (MAC étendu = e6cdd2d93249a243
) s'est transformé en routeur. Notez que le niveau d'impact RTL16 est différent (b800
au lieu de 0c02
). En effet, le RTL16 est basé sur l'ID de routeur et l'ID enfant d'un appareil. Lors de la transition d'un appareil final vers un routeur, les valeurs de son ID de routeur et de son ID d'enfant changent, tout comme le Rloc16.
Confirmez le nouvel état et le code RTL16 sur l'opérateur FTD Joiner:
## FTD Joiner ## ---------------- > state router Done > rloc16 b800 Done
Rétrograder FTD Joiner
Vous pouvez tester ce comportement en revenant manuellement à une édition FTD Joiner d'un routeur sur un Appareil final. Définissez l'état sur "child" (enfant) et vérifiez le Rloc16:
## FTD Joiner ## ---------------- > state child Done > rloc16 0c03 Done
Sur l'écran du commissaire FTD, le Joint FTD devrait maintenant apparaître dans la table enfant (ID = 3). Elle peut se trouver dans les deux cas pendant la transition:
## FTD Commissioner ## ---------------------- > router table | ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC | +----+--------+----------+-----------+-------+--------+-----+------------------+ | 3 | 0x0c00 | 3 | 0 | 0 | 0 | 50 | 1ed687a9cb9d4b1d | | 46 | 0xb800 | 63 | 0 | 3 | 3 | 1 | e6cdd2d93249a243 | > child table | ID | RLOC16 | Timeout | Age | LQ In | C_VN |R|S|D|N| Extended MAC | +-----+--------+------------+------------+-------+------+-+-+-+-+------------------+ | 1 | 0x0c01 | 240 | 61 | 3 | 89 |1|1|1|1| 1ae529b3a638943b | | 3 | 0x0c03 | 240 | 16 | 3 | 94 |1|1|1|1| e6cdd2d93249a243 | Done
Après un certain temps, elle sera rétablie à l'aide d'un routeur avec un Rloc de b800
.
Supprimer la variante optimale
La variante optimale est auto-élue parmi tous les routeurs à thread. Cela signifie que si le responsable actuel est supprimé du réseau Thread, l'un des autres routeurs deviendra le nouveau responsable.
Dans le cadre du 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 responsable Thread. Vérifiez l'état et les adresses IPv6 du jointur FTD:
## FTD Joiner ## ---------------- > state leader Done > ipaddr fdc0:de7a:b5c0:0:0:ff:fe00:fc00 # Now it has the Leader ALOC! fdc0:de7a:b5c0:0:0:ff:fe00:b800 fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd fe80:0:0:0:e4cd:d2d9:3249:a243 Done
Vérifiez la table enfant. Vous remarquerez qu'il existe un nouveau Rloc16. Il s'agit du Joint RCP, indiqué par son ID et son adresse MAC étendue. Pour maintenir le réseau Thread, il a changé les routeurs parents du commissaire FTD au jointeur FTD. Cela entraîne un nouveau Rloc16 pour le jointur 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 patienter quelques minutes, le temps que le participant RPC s'associe au jointeur FTD en tant qu'enfant. Vérifiez l'état et le Rloc16 pour confirmer que:
## RCP Joiner ## -------------- > state child > rloc16 b801
Réintégrer le commissaire FTD
Un réseau Thread avec deux nœuds n'est pas très amusant. Remettons le commissaire de FTD en ligne.
Dans le cadre du 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 "atelier de programmation" en tant qu'appareil de fin, puis se transforme en routeur.
## FTD Commissioner ## ---------------------- > state router Done
Consultez le routeur et les tables enfants du 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 est à nouveau composé de trois nœuds.
11. Dépannage
La gestion d'un réseau Thread avec plusieurs appareils sur différentes fenêtres de terminal ou d'écran peut être complexe. 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 vous perdez lors d'une opération de configuration (trop de fenêtres d'écran ou d'écrans à l'écran), arrêtez de fermer les fenêtres avec Ctrl+a kk jusqu'à ce qu'il n'en ait aucune, et screen -ls
sur la ligne de commande renvoie No Sockets found
. Ensuite, recréez des fenêtres d'écran pour chaque appareil. Les états de l'appareil 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 à la description décrite dans cet atelier de programmation ou si les nœuds se déconnectent pour une raison quelconque (par exemple parce que la machine Linux qui les alimente est passée en veille), il est préférable d'arrêter Thread, d'effacer les identifiants réseau et de recommencer depuis la page Créez le réseau Thread.
Pour réinitialiser les temps de trajet, procédez comme suit:
## 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
La multidiffusion permet de communiquer des informations à un groupe d'appareils en même temps. Dans un réseau Thread, les adresses spécifiques sont réservées à l'utilisation de multidiffusion avec différents groupes d'appareils, en fonction du champ d'application.
Adresse IPv6 | Scope (Portée) | Livré à |
| Lien local | Toutes les valeurs FTD et MED |
| Lien local | Tous les flux de données et les routeurs de bordure |
| Locale (maille) | Toutes les valeurs FTD et MED |
| Locale (maille) | Tous les flux de données et les routeurs de bordure |
Comme nous n'utilisons pas de routeur de bordure dans cet atelier de programmation, nous allons nous concentrer 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 "saut" unique. La topologie du réseau spécifie les appareils qui répondent à un ping vers l'adresse de multidiffusion ff02::1
.
Pinguez ff02::1
depuis le commissaire FTD:
## FTD Commissioner ## ---------------------- > ping ff02::1 > 8 bytes from fe80:0:0:0:e4cd:d2d9:3249:a243: icmp_seq=2 hlim=64 time=9ms
Il y a deux autres appareils sur le réseau (FTD Joiner et RCP Joiner), mais le commissaire à la conférence FTD n'a reçu qu'une réponse de la part de FTD Joiner's Link-Local Address (LLA). Cela signifie que le jointeur FTD est le seul appareil que le commissaire FTD peut atteindre avec un seul saut.
Pinguez maintenant ff02::1
depuis FTD Joiner:
## FTD Joiner ## ---------------- > ping ff02::1 > 8 bytes from fe80:0:0:0:1cd6:87a9:cb9d:4b1d: icmp_seq=1 hlim=64 time=11ms 8 bytes from fe80:0:0:0:18e5:29b3:a638:943b: icmp_seq=1 hlim=64 time=24ms
Deux réponses ! En vérifiant les adresses IPv6 des autres appareils, nous pouvons voir que le premier (se terminant par 4b1d
) est le LLA du commissaire aux services d'urgence et le second (qui se termine par 943b
) est le LLA du commissaire RCP.
Cela signifie que le jointeur FTD est directement connecté au commissaire FTD et au Jointeur RCP, ce qui confirme notre topologie.
Locale (maille)
Le champ d'application Mesh-Local comprend toutes les interfaces Thread accessibles au sein du même réseau Thread. Examinons les réponses à un ping vers l'adresse de multidiffusion ff03::1
.
Pinguez ff03::1
depuis le commissaire FTD:
## FTD Commissioner ## ---------------------- > ping ff03::1 > 8 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:b800: icmp_seq=3 hlim=64 time=9ms 8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=3 hlim=64 time=68ms
Cette fois, le commissaire à la certification FTD a reçu deux réponses, l'une provenant du localisateur de routage de l'opérateur de jointure FTD (RLO se terminant par b800
) et l'autre provenant du numéro EID de jointure RCP (ML-EID, se terminant par d55f
). En effet, le champ d'application local du réseau maillé comprend l'ensemble du réseau Thread. Peu importe où se trouve un appareil sur le réseau, il est abonné à l'adresse ff03::1
.
Pinguez ff03::1
depuis le membre 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 du jointur RCP dans les deux sorties ping. Le RCP Joiner a mis plus de temps à joindre le commissaire FTD (68 ms) qu'à atteindre le Jointeur FTD (23 ms). C'est parce qu'il doit faire deux sauts pour atteindre le commissaire FTD, contre un saut pour le FTD Joiner.
Vous avez peut-être également remarqué que le ping multicast local de maillage a répondu avec le RTL uniquement pour les deux FTD, et non le Joint RCP. car les FTD sont des routeurs au sein du réseau, tandis que le RCP est un appareil final.
Vérifiez l'état du membre du programme PRC pour confirmer:
## RCP Joiner ## ---------------- > state child
13. Envoyer des messages avec UDP
L'un des services d'application fournis par OpenThread est le protocole de datagramme utilisateur (UDP), un protocole de couche de transport. Une application basé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 dans un réseau externe (comme Internet, si le réseau Thread possède un routeur de bordure).
Les sockets UDP sont exposés via la CLI OpenThread. Nous allons l'utiliser pour transmettre les messages entre les deux flux.
Obtenez l'adresse EID locale du maillage pour le jointur FTD. Nous utilisons cette adresse, car elle est accessible depuis n'importe où au sein 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 au commissaire FTD, démarrez UDP et connectez-vous au socket que vous avez configuré sur le FTD Joiner, en utilisant son ML-EID:
## FTD Commissioner ## ---------------------- > udp open Done > udp connect fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd 1212 Done
La connexion UDP doit être active entre les deux nœuds. Envoyez un message au commissaire FTD:
## FTD Commissioner ## ---------------------- > udp send hellothere Done
Sur la pageJointeur FTD, le message UDP a été reçu.
## FTD Joiner ## ---------------- > 10 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00 49153 hellothere
14. Félicitations !
Vous avez créé un réseau Thread physique.
Vous savez maintenant:
- Différence entre les types d'appareils Thread, les rôles et les habilitations
- Comment les appareils Thread gèrent leur état au sein du réseau
- comment transmettre des messages simples entre les nœuds à l'aide d'UDP
Liens associés
Pour développer cet atelier de programmation, essayez les exercices suivants:
- Retransformez la carte Joint FTD en tant que MTD à l'aide du binaire
ot-cli-mtd
et observez qu'elle ne se transforme jamais en routeur ou tente de devenir la variante optimale. - Ajoutez d'autres appareils au réseau (essayez une autre plate-forme), et esquissez la topologie en utilisant les tables de routeur et enfant, ainsi que des pings vers les adresses de multidiffusion.
- Utiliser le pyspinel pour contrôler le NCP
- Convertissez le NCP en routeur de bordure à l'aide du routeur de bordure ThreadThread et connectez votre réseau Thread à Internet
Documentation complémentaire
Consultez openthread.io et GitHub pour accéder à diverses ressources OpenThread, y compris:
- Supported Platforms (Plates-formes compatibles) : découvrez toutes les plates-formes compatibles avec OpenThread
- Build OpenThread - Plus de détails sur la création et la configuration d'OpenThread
- Thread Prime : présente tous les concepts de Thread présentés dans cet atelier de programmation
Références :