1. Introduction
Qu'est-ce que Thread ?
Thread est un protocole de réseau maillé sans fil basse consommation basé sur IP qui permet de communiquer de manière sécurisée entre les appareils et le cloud. Les réseaux Thread peuvent s'adapter aux modifications de la topologie pour éviter les défaillances ponctuelles.
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 l'adresse IP, tels que le Wi-Fi ou l'Ethernet. Un réseau Thread nécessite un routeur de bordure pour se connecter à d'autres réseaux. Un routeur de bordure Thread est compatible avec les fonctions suivantes au minimum:
- Connectivité IP bidirectionnelle entre les réseaux Thread et Wi-Fi/Ethernet
- Découverte de services bidirectionnelle via mDNS (sur la liaison Wi-Fi/Ethernet) et SRP (sur le réseau Thread).
- Thread sur l'infrastructure qui fusionne les partitions Thread sur des liens basés sur l'IP.
- Mise en service Thread externe (par exemple, un téléphone mobile) pour authentifier et associer un appareil Thread à 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 avec 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 dongles USB nRF52840 Nordic Semiconductor (un pour le RCP et un 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 l'OTBR
Le moyen le plus rapide de configurer un OTBR est de suivre le guide de configuration de l'OTBR.
Une fois la configuration de l'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 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 l'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 nRF52840 avec la CLI.
Toutefois, au lieu d'activer OT_COMMISSIONER et OT_JOINER, le nœud de la CLI nécessite les fonctionnalités OT_SRP_CLIENT et OT_ECDSA.
L'appel de compilation complet doit donc 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érationnel actif de l'appareil OTBR. Revenons à ot-ctl et obtenons le jeu 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 et vérifiez si l'association au réseau Thread a réussi:
> 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 réseau correspondent à celles imprimées sur l'OTBR. Nous pouvons maintenant envoyer un ping à l'adresse OMR d'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
Le mDNS a été largement utilisé pour publier le service DNS-SD sur le lien local. 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 unicast pour enregistrer ses services auprès du routeur de bordure et s'appuie sur ce dernier pour annoncer les services sur le lien Wi-Fi ou Ethernet.
Nous pouvons enregistrer un service à l'aide de 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 diffusé sur le lien Wi-Fi/Ethernet:
> srp client host name ot-host Done
Pour qu'un appareil sur le lien Wi-Fi/Ethernet puisse atteindre un dispositif 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
À la fin, enregistrez un faux service _ipps._tcp:
> srp client service add ot-service _ipps._tcp 12345 Done
Patientez quelques secondes. Le service devrait être enregistré:
> srp client service instance:"ot-service", name:"_ipps._tcp", state:Registered, port:12345, priority:0, weight:0 Done
Nous avons terminé la 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 à partir d'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 sous macOS pour résoudre le problème:
$ 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
Ping 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 de l'OMR avec une autre application Network Analyzer.
Malheureusement, la version Android de l'application Network Analyzer n'est pas compatible avec les requêtes mDNS pour l'utilitaire ping. Nous ne pouvons donc pas envoyer de ping directement au nom d'hôte ot-host.local (nous pouvons le faire avec la version iOS de l'application).
Ping depuis un hôte Linux/macOS
Le routeur de bord Thread envoie des annonces de routeur (RA) ICMPv6 pour annoncer des préfixes (via l'option d'informations sur le préfixe) et des routes (via l'option d'informations sur la route) sur le lien Wi-Fi/Ethernet.
Préparer l'hôte Linux
Il est important de vous assurer que RA et RIO sont activés sur votre hôte:
net.ipv6.conf.wlan0.accept_radoit être au moins1si le transfert d'adresses IP n'est pas activé, et2dans le cas contraire.net.ipv6.conf.wlan0.accept_ra_rt_info_max_plenne doit pas être inférieur à64.
La valeur par défaut de accept_ra est 1 pour la plupart des distributions. Toutefois, d'autres daemons réseau peuvent remplacer cette option (par exemple, dhcpcd sur Raspberry Pi remplace accept_ra par 0). Vous pouvez vérifier la valeur accept_ra avec:
$ 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
La valeur par défaut de l'option accept_ra_rt_info_max_plen sur la plupart des distributions Linux est 0. Définissez-la sur 64 avec:
$ 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
Le changement sera perdu après le redémarrage de l'hôte. Par exemple, ajoutez les commandes ci-dessous à /etc/sysctl.conf pour activer définitivement RIO:
$ net.ipv6.conf.wlan0.accept_ra_rt_info_max_plen = 64
Il est peut-être trop tard pour modifier ces configurations, car l'OTBR a déjà envoyé des messages RA et l'intervalle entre deux messages RA non sollicités peut être de plusieurs centaines de secondes. Pour ce faire, vous pouvez vous déconnecter et vous reconnecter au point d'accès Wi-Fi afin d'envoyer des messages de sollicitation de routeur afin que l'OTBR réponde avec des RA sollicités. Vous pouvez également 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 est perdue. Ajoutez les lignes ci-dessous au fichier de configuration dhcpcd (par exemple, /etc/dhcpcd.conf) pour désactiver explicitement l'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 à l'aide de 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 des 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 entendu, vous pouvez toujours effectuer un ping directement sur 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. Fin de la publication du service sur l'appareil
Pour supprimer l'adresse et le service enregistrés du nœud client SRP:
> srp client host remove Done
Vous ne devriez pas pouvoir détecter le service _ipps._tcp pour le moment.
8. Félicitations
Félicitations, vous avez correctement configuré l'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...