1. Introduction
Qu'est-ce que Thread ?
Thread est un protocole de réseau maillé sans fil basse consommation basé sur IP qui permet des communications sécurisées entre appareils et entre appareils et le cloud. Les réseaux Thread peuvent s'adapter aux changements de topologie pour éviter les points de défaillance uniques.
Qu'est-ce qu'OpenThread ?
OpenThread publié par Google est une implémentation Open Source de Thread®.
Qu'est-ce qu'un routeur de bordure Thread ?
Un routeur de bordure Thread connecte un réseau Thread à d'autres réseaux basés sur IP, tels que le Wi-Fi ou Ethernet. Un réseau Thread nécessite un routeur de bordure pour se connecter à d'autres réseaux. Un routeur de bordure Thread doit au minimum prendre en charge les fonctions suivantes :
- Connectivité IP bidirectionnelle entre les réseaux Thread et Wi-Fi/Ethernet.
- Détection de services bidirectionnelle via mDNS (sur la liaison Wi-Fi/Ethernet) et SRP (sur le réseau Thread).
- Thread-over-infrastructure qui fusionne les partitions Thread sur des liens basés sur IP.
- Mise en service Thread externe (par exemple, un téléphone mobile) pour authentifier un appareil Thread et le joindre à un réseau Thread.
Le routeur de bordure OpenThread (OTBR) publié par Google est une implémentation Open Source du routeur de bordure Thread.
Ce que vous allez faire
Dans cet atelier de programmation, vous allez configurer un routeur de bordure Thread et connecter votre téléphone mobile à un appareil final Thread via le routeur de bordure.
Points abordés
- Configurer OTBR
- Former un réseau Thread avec OTBR
- Créer un appareil OpenThread CLI avec la fonctionnalité SRP
- Enregistrer un service auprès de SRP
- Découvrir et contacter un appareil final Thread
Prérequis
- Un poste de travail Linux pour créer et flasher un RCP Thread, la CLI OpenThread et tester le multicast IPv6.
- Un Raspberry Pi pour le routeur de bordure Thread.
- Deux clés USB Nordic Semiconductor nRF52840 (une pour le RCP et une pour l'appareil final Thread).
- Un téléphone iOS avec au moins iOS 14 ou un téléphone Android avec au moins Android 8.1.
2. Configurer OTBR
Le moyen le plus rapide de configurer un OTBR consiste à suivre le guide de configuration OTBR.
Une fois la configuration OTBR terminée, utilisez ot-ctl pour vérifier que l'OTBR agit en tant que leader Thread.
$ sudo ot-ctl state leader Done
Vérifiez également que l'OTBR a automatiquement configuré un préfixe off-mesh-routable (OMR) dans les données du réseau Thread.
$ sudo ot-ctl netdata show Prefixes: Prefixes: fd76:a5d1:fcb0:1707::/64 paos med 4000 Routes: fd49:7770:7fc5:0::/64 s med 4000 Services: 44970 5d c000 s 4000 44970 01 9a04b000000e10 s 4000 Done $ sudo ot-ctl ipaddr fda8:5ce9:df1e:6620:0:ff:fe00:fc11 fda8:5ce9:df1e:6620:0:0:0:fc38 fda8:5ce9:df1e:6620:0:ff:fe00:fc10 fd76:a5d1:fcb0:1707:f3c7:d88c:efd1:24a9 fda8:5ce9:df1e:6620:0:ff:fe00:fc00 fda8:5ce9:df1e:6620:0:ff:fe00:4000 fda8:5ce9:df1e:6620:3593:acfc:10db:1a8d fe80:0:0:0:a6:301c:3e9f:2f5b Done
3. Configurer un appareil client SRP
Compiler et flasher la CLI OT
Suivez l'étape 5 de l'atelier de programmation Créer un réseau Thread avec des cartes nRF52840 et OpenThread pour créer et flasher un appareil final CLI nRF52840.
Toutefois, au lieu d'activer OT_COMMISSIONER et OT_JOINER, le nœud CLI nécessite les fonctionnalités OT_SRP_CLIENT et OT_ECDSA.
L'invocation de compilation complète doit se présenter comme suit :
$ script/build nrf52840 USB_trans -DOT_SRP_CLIENT=ON -DOT_ECDSA=ON
Rejoindre le réseau Thread
Pour rejoindre le réseau Thread, nous devons obtenir l'ensemble de données opérationnelles actives à partir de l'appareil OTBR. Revenons à ot-ctl et obtenons l'ensemble de données actif :
$ sudo ot-ctl dataset active -x 0e080000000000010000000300001235060004001fffe002083d3818dc1c8db63f0708fda85ce9df1e662005101d81689e4c0a32f3b4aa112994d29692030f4f70656e5468726561642d35326532010252e204103f23f6b8875d4b05541eeb4f9718d2f40c0302a0ff Done
Revenez à la session d'écran du nœud client SRP et définissez l'ensemble de données actif :
> dataset set active 0e080000000000010000000300001235060004001fffe002083d3818dc1c8db63f0708fda85ce9df1e662005101d81689e4c0a32f3b4aa112994d29692030f4f70656e5468726561642d35326532010252e204103f23f6b8875d4b05541eeb4f9718d2f40c0302a0ff Done
Ensuite, démarrez l'interface Thread :
> ifconfig up Done > thread start Done
Attendez quelques secondes, puis vérifiez que l'appareil a bien rejoint le réseau Thread :
> state child Done > netdata show Prefixes: fd76:a5d1:fcb0:1707::/64 paos med 4000 Routes: fd49:7770:7fc5:0::/64 s med 4000 Services: 44970 5d c000 s 4000 44970 01 9a04b000000e10 s 4000 Done > ipaddr fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927 fda8:5ce9:df1e:6620:0:ff:fe00:4001 fda8:5ce9:df1e:6620:ed74:123:cc5d:74ba fe80:0:0:0:d4a9:39a0:abce:b02e Done
Assurez-vous que les données du réseau correspondent à celles imprimées sur l'OTBR. Nous pouvons maintenant envoyer un ping à l'adresse OMR de l'OTBR :
> ping fd76:a5d1:fcb0:1707:f3c7:d88c:efd1:24a9 Done > 16 bytes from fd76:a5d1:fcb0:1707:f3c7:d88c:efd1:24a9: icmp_seq=1 hlim=64 time=49ms
4. Publier le service sur l'appareil final
mDNS est largement utilisé pour publier le service DNS-SD sur la liaison locale. Toutefois, les messages multicast consomment trop de bande passante et déchargent rapidement la batterie des appareils à faible consommation d'énergie. Thread utilise le protocole SRP en monodiffusion pour enregistrer ses services auprès du routeur de bordure et s'appuie sur le routeur de bordure pour annoncer les services sur la liaison Wi-Fi ou Ethernet.
Nous pouvons enregistrer un service avec la commande srp client.
Accédez à la session d'écran du nœud client SRP et démarrez automatiquement le client SRP :
> srp client autostart enable Done
Définissez le nom d'hôte qui sera annoncé sur la liaison Wi-Fi/Ethernet :
> srp client host name ot-host Done
Pour qu'un appareil connecté en Wi-Fi/Ethernet puisse atteindre un appareil final Thread, l'adresse OMR de l'appareil final doit être annoncée :
> srp client host address fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927 Done
Enfin, enregistrez un faux service _ipps._tcp :
> srp client service add ot-service _ipps._tcp 12345 Done
Patientez quelques secondes, puis vous devriez voir le service enregistré :
> srp client service instance:"ot-service", name:"_ipps._tcp", state:Registered, port:12345, priority:0, weight:0 Done
Nous avons terminé toutes les tâches de configuration. Le service _ipps._tcp aurait dû être annoncé sur le lien Wi-Fi/Ethernet. Il est temps de découvrir et d'atteindre l'appareil final !
5. Découvrir le service
Découvrir le service avec un téléphone mobile
Nous utilisons l'application Service Browser pour découvrir les services mDNS avec le téléphone Android. Une application équivalente est également disponible pour les appareils mobiles iOS. Ouvrez l'application. Le service _ipps._tcp devrait s'afficher.
Découvrir le service avec un hôte Linux
Si vous souhaitez découvrir le service depuis un autre hôte Linux, vous pouvez utiliser la commande avahi-browse.
Installez avahi-daemon et avahi-utils :
$ sudo apt-get install -y avahi-daemon avahi-utils
Résolvez le service :
$ sudo service avahi-daemon start # Ensure the avahi daemon is started. $ avahi-browse -r _ipps._tcp + wlan0 IPv6 ot-service Secure Internet Printer local = wlan0 IPv6 ot-service Secure Internet Printer local hostname = [ot-host.local] address = [fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927] port = [12345] txt = [] ...
Découvrir le service avec un hôte macOS
Vous pouvez utiliser dns-sd sur macOS pour résoudre le problème de service :
$ dns-sd -Z _ipps._tcp local. Browsing for _ipps._tcp.local. DATE: ---Sun 14 Mar 2021--- 21:31:42.125 ...STARTING... ; To direct clients to browse a different domain, substitute that domain in place of '@' lb._dns-sd._udp PTR @ ; In the list of services below, the SRV records will typically reference dot-local Multicast DNS names. ; When transferring this zone file data to your unicast DNS server, you'll need to replace those dot-local ; names with the correct fully-qualified (unicast) domain name of the target host offering the service. _ipps._tcp PTR ot-service._ipps._tcp ot-service._ipps._tcp SRV 0 0 12345 ot-host.local. ; Replace with unicast FQDN of target host ot-service._ipps._tcp TXT "" ...
6. Envoyer un ping à l'appareil final
Pinguer depuis un téléphone mobile
Prenons l'exemple du téléphone Pixel. Nous pouvons trouver l'adresse OMR du service "ot-service" précédemment enregistré sur la page d'informations de l'instance de service dans l'application Service Browser.
Nous pouvons maintenant envoyer un ping à l'adresse OMR avec une autre application Network Analyzer.
Malheureusement, la version Android de l'application Analyseur de réseau n'est pas compatible avec les requêtes mDNS pour l'utilitaire ping. Nous ne pouvons donc pas envoyer de requête ping directement au nom d'hôte ot-host.local (nous pouvons le faire avec la version iOS de l'application).
Effectuer un ping depuis un hôte Linux/macOS
Le routeur de bordure Thread envoie des annonces de routeur ICMPv6 (RA) pour annoncer les préfixes (via l'option d'informations sur le préfixe) et les routes (via l'option d'informations sur la route) sur la liaison Wi-Fi/Ethernet.
Préparer l'hôte Linux
Il est important de s'assurer que l'accès à distance et l'entrée/sortie à distance sont activés sur votre hôte :
net.ipv6.conf.wlan0.accept_radoit être au moins égal à1si le transfert IP n'est pas activé, et à2dans le cas contraire.net.ipv6.conf.wlan0.accept_ra_rt_info_max_plenne doit pas être inférieur à64.
accept_ra est défini sur 1 par défaut pour la plupart des distributions. Toutefois, d'autres daemons réseau peuvent remplacer cette option (par exemple, dhcpcd sur Raspberry Pi remplacera accept_ra par 0). Vous pouvez vérifier la valeur de accept_ra avec la commande suivante :
$ sudo sysctl -n net.ipv6.conf.wlan0.accept_ra 0
Définissez la valeur sur 1 (ou 2 si le transfert IP est activé) avec :
$ sudo sysctl -w net.ipv6.conf.wlan0.accept_ra=1 Net.ipv6.conf.wlan0.accept_ra = 1
L'option accept_ra_rt_info_max_plen de la plupart des distributions Linux est définie par défaut sur 0. Définissez-la sur 64 avec la commande suivante :
$ sudo sysctl -w net.ipv6.conf.wlan0.accept_ra_rt_info_max_plen=64 net.ipv6.conf.wlan0.accept_ra_rt_info_max_plen = 64
La modification sera perdue après le redémarrage de l'hôte. Par exemple, ajoutez les commandes ci-dessous à /etc/sysctl.conf pour activer RIO de manière permanente :
$ net.ipv6.conf.wlan0.accept_ra_rt_info_max_plen = 64
Il est peut-être trop tard pour modifier ces configurations, car l'OTBR envoie déjà des messages RA et l'intervalle entre deux messages RA non sollicités peut être de plusieurs centaines de secondes. Une solution consiste à se déconnecter et à se reconnecter au point d'accès Wi-Fi pour envoyer des messages de sollicitation de routeur afin que l'OTBR réponde avec des RA sollicitées. Une autre option consiste à redémarrer la fonction de routage de bordure sur le routeur de bordure :
$ sudo ot-ctl br disable Done $ sudo ot-ctl br enable Done
Si vous essayez de reconnecter le Wi-Fi ou de redémarrer l'interface Ethernet, assurez-vous que dhcpcd n'est pas utilisé pour gérer votre réseau IPv6 Wi-Fi/Ethernet. En effet, dhcpcd remplace toujours l'option accept_ra chaque fois que l'interface est redémarrée, et votre configuration accept_ra sera perdue. Ajoutez les lignes ci-dessous au fichier de configuration dhcpcd (par exemple, /etc/dhcpcd.conf) pour désactiver explicitement IPv6 dans dhcpcd :
noipv6 noipv6rs
Vous devez redémarrer pour que la modification prenne effet.
Préparer l'hôte macOS
Les deux options accept_ra* sont activées par défaut, mais vous devez mettre à niveau votre système vers au moins macOS Big Sur.
Envoyer un ping au nom d'hôte ou à l'adresse IPv6
Nous pouvons maintenant envoyer un ping au nom d'hôte ot-host.local avec la commande ping -6 (ping6 pour macOS) :
$ ping -6 ot-host.local. PING ot-host.local.(fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927 (fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927)) 56 data bytes 64 bytes from fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927 (fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927): icmp_seq=1 ttl=63 time=170 ms 64 bytes from fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927 (fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927): icmp_seq=2 ttl=63 time=64.2 ms 64 bytes from fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927 (fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927): icmp_seq=3 ttl=63 time=22.8 ms 64 bytes from fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927 (fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927): icmp_seq=4 ttl=63 time=37.7 ms 64 bytes from fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927 (fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927): icmp_seq=5 ttl=63 time=28.7 ms ...
Cette commande peut échouer sur les hôtes Linux avec l'erreur "Name or service not known". En effet, la commande ping ne résout pas le nom ot-host.local. avec les requêtes mDNS. Ouvrez /etc/nsswitch.conf et ajoutez mdns6_minimal à la ligne commençant par hosts :
hosts: files mdns4_minimal mdns6_minimal dns
Bien sûr, vous pouvez toujours envoyer un ping directement à l'adresse IPv6 :
$ ping -6 fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927 PING fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927(fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927) 56 data bytes 64 bytes from fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927: icmp_seq=1 ttl=63 time=32.9 ms 64 bytes from fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927: icmp_seq=2 ttl=63 time=27.8 ms 64 bytes from fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927: icmp_seq=3 ttl=63 time=29.9 ms 64 bytes from fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927: icmp_seq=4 ttl=63 time=73.5 ms 64 bytes from fd76:a5d1:fcb0:1707:d3dc:26d3:f70b:b927: icmp_seq=5 ttl=63 time=26.4 ms ...
7. Annuler la publication du service sur l'appareil final
Pour supprimer l'adresse et le service enregistrés à partir du nœud client SRP :
> srp client host remove Done
Vous ne devriez pas pouvoir découvrir le service _ipps._tcp maintenant.
8. Félicitations
Félicitations, vous avez configuré OTBR en tant que routeur de bordure Thread pour fournir une connectivité IP bidirectionnelle et la découverte de services pour les appareils finaux Thread.
Étape suivante
Découvrez quelques-uns des ateliers de programmation...