1. Einführung
OpenThread von Google ist eine Open-Source-Implementierung des Thread®-Netzwerkprotokolls. Google Nest hat OpenThread veröffentlicht, um die in Nest-Produkten verwendete Technologie Entwicklern zur Verfügung zu stellen und so die Entwicklung von Produkten für das vernetzte Zuhause zu beschleunigen.
Die Thread-Spezifikation definiert ein zuverlässiges, sicheres und energieeffizientes IPv6-basiertes Protokoll für die drahtlose Kommunikation zwischen Geräten für Anwendungen im Haushalt. OpenThread implementiert alle Thread-Netzwerkschichten, einschließlich IPv6, 6LoWPAN, IEEE 802.15.4 mit MAC-Sicherheit, Mesh Link Establishment und Mesh Routing.
In diesem Codelab programmieren Sie OpenThread auf echter Hardware, erstellen und verwalten ein Thread-Netzwerk und übergeben Nachrichten zwischen Knoten.
Lerninhalte
- OpenThread-Befehlszeilenbinärdateien für Entwicklerboards erstellen und flashen
- RCP aus einer Linux-Maschine und einem Entwicklungsboard erstellen
- Kommunikation mit einem RCP über OpenThread Daemon und
ot-ctl - Thread-Knoten manuell mit GNU Screen und der OpenThread-CLI verwalten
- Sichere Inbetriebnahme von Geräten in einem Thread-Netzwerk
- So funktioniert IPv6-Multicast
- Nachrichten zwischen Thread-Knoten mit UDP übergeben
Voraussetzungen
Hardware:
- 3 Nordic Semiconductor nRF52840-Entwicklerboards
- 3 USB-zu-Micro-USB-Kabel zum Verbinden der Boards
- Ein Linux-Computer mit mindestens drei USB-Anschlüssen
Software:
- GNU-Toolchain
- Nordic nRF5x-Befehlszeilentools
- Segger J-Link-Software
- OpenThread
- Git
2. Erste Schritte
OpenThread-Simulation
Bevor Sie beginnen, sollten Sie das OpenThread-Simulations-Codelab durcharbeiten, um sich mit den grundlegenden Thread-Konzepten und der OpenThread-Befehlszeile vertraut zu machen.
Terminals für serielle Ports
Sie sollten wissen, wie Sie über ein Terminal eine Verbindung zu einem seriellen Port herstellen. In diesem Codelab wird GNU Screen verwendet. Es wird eine Übersicht zur Verwendung bereitgestellt, aber Sie können auch jede andere Terminalsoftware verwenden.
Linux-Computer
Dieses Codelab wurde für die Verwendung einer i386- oder x86-basierten Linux-Maschine als Host für ein Radio Co-Processor (RCP) Thread-Gerät und zum Flashen aller Thread-Entwicklungsboards entwickelt. Alle Schritte wurden unter Ubuntu 14.04.5 LTS (Trusty Tahr) getestet.
Nordic Semiconductor nRF52840-Boards
In diesem Codelab werden drei nRF52840 PDK-Boards verwendet.
SEGGER J-Link installieren
Wir verwenden SEGGER J-Link, um die nRF52840-Boards zu programmieren, die integrierte JTAG-Module haben. Installieren Sie das Tool auf Ihrem Linux-Computer.
Laden Sie das entsprechende Paket für Ihren Computer herunter und installieren Sie es am richtigen Speicherort. Unter Linux ist das /opt/SEGGER/JLink.
nRF5x-Befehlszeilentools installieren
Mit den nRF5x Command Line Tools können Sie die OpenThread-Binärdateien auf die nRF52840-Boards flashen. Installieren Sie den entsprechenden Build von nRF5x-Command-Line-Tools-<OS> auf Ihrem Linux-Computer.
Legen Sie das extrahierte Paket in den Stammordner ~/.
ARM GNU Toolchain installieren
Die ARM GNU Toolchain wird für den Build verwendet.
Wir empfehlen, das extrahierte Archiv auf Ihrem Linux-Computer in /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/ zu platzieren. Folgen Sie der Anleitung in der Datei readme.txt des Archivs.
Bildschirm installieren (optional)
Screen ist ein einfaches Tool für den Zugriff auf Geräte, die über einen seriellen Port verbunden sind. In diesem Codelab wird Screen verwendet. Sie können aber auch eine beliebige andere Terminalanwendung für den seriellen Port verwenden.
$ sudo apt-get install screen
3. Repositorys klonen
OpenThread
OpenThread klonen und installieren. Mit den script/bootstrap-Befehlen wird sichergestellt, dass die Toolchain installiert und die Umgebung richtig konfiguriert ist:
$ mkdir -p ~/src $ cd ~/src $ git clone --recursive https://github.com/openthread/openthread.git $ cd openthread $ ./script/bootstrap
OpenThread-Daemon erstellen:
$ script/cmake-build posix -DOT_DAEMON=ON
Jetzt können Sie OpenThread für die nRF52840-Boards erstellen und flashen.
4. RCP Joiner einrichten
Erstellen und flashen
Erstellen Sie das OpenThread-Beispiel für nRF52840 mit Joiner- und nativer USB-Funktionalität. Ein Gerät verwendet die Joiner-Rolle, um sicher authentifiziert und in einem Thread-Netzwerk in Betrieb genommen zu werden. Native USB ermöglicht die Verwendung von USB CDC ACM als seriellen Transport zwischen dem nRF52840 und dem Host.
Bereinigen Sie das Repository immer zuerst von vorherigen Builds, indem Sie rm -rf build ausführen.
$ cd ~/src $ git clone --recursive https://github.com/openthread/ot-nrf528xx.git $ cd ot-nrf528xx $ script/build nrf52840 USB_trans
Wechseln Sie in das Verzeichnis mit dem OpenThread RCP-Binärprogramm und konvertieren Sie es in das Hexadezimalformat:
$ cd ~/src/ot-nrf528xx/build/bin $ arm-none-eabi-objcopy -O ihex ot-rcp ot-rcp.hex
Schließen Sie das USB-Kabel an den Micro-USB-Debug-Anschluss neben dem externen Stromanschluss auf dem nRF52840-Board an und verbinden Sie es dann mit dem Linux-Computer. Stellen Sie den Schalter nRF power source auf dem nRF52840-Board auf VDD ein. Bei korrekter Verbindung leuchtet LED5.
Wenn dies das erste Board ist, das an die Linux-Maschine angeschlossen wird, wird es als serieller Port /dev/ttyACM0 angezeigt. Alle nRF52840-Boards verwenden ttyACM als Kennung für den seriellen Port.
$ ls /dev/ttyACM* /dev/ttyACM0
Notieren Sie sich die Seriennummer des nRF52840-Boards, das für die RCP verwendet wird:
Rufen Sie den Speicherort der nRFx Command Line Tools auf und flashen Sie die OpenThread RCP-Hex-Datei auf das nRF52840-Board. Verwenden Sie dazu die Seriennummer des Boards. Wenn Sie das Flag --verify weglassen, wird eine Warnmeldung angezeigt, dass der Flash-Vorgang ohne Fehler fehlschlagen kann.
$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
~/src/ot-nrf528xx/build/bin/ot-rcp.hex --reset
Bei Erfolg wird die folgende Ausgabe generiert:
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.
Labeln Sie das Board mit „RCP“, damit Sie die Boardrollen später nicht verwechseln.
Mit nativem USB verbinden
Da der OpenThread-RCP-Build die Verwendung von nativem USB CDC ACM als seriellen Transport ermöglicht, müssen Sie den nRF USB-Port auf dem nRF52840-Board verwenden, um mit dem RCP-Host (Linux-Computer) zu kommunizieren.
Trennen Sie das Micro-USB-Ende des USB-Kabels vom Debug-Port des geflashten nRF52840-Boards und schließen Sie es dann wieder an den Micro-USB-Port nRF USB neben der RESET-Taste an. Stellen Sie den Schalter nRF power source auf USB.
OpenThread-Daemon starten
Verwenden Sie im RCP-Design den OpenThread-Daemon, um mit dem Thread-Gerät zu kommunizieren und es zu verwalten. Starten Sie ot-daemon mit dem Verbose-Flag -v, damit Sie die Log-Ausgabe sehen und bestätigen können, dass der Dienst ausgeführt wird:
$ cd ~/src/openthread
$ sudo ./build/posix/src/posix/ot-daemon -v \
'spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=460800'
Bei erfolgreicher Ausführung wird in ot-daemon im ausführlichen Modus eine Ausgabe ähnlich der folgenden generiert:
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
Lassen Sie dieses Terminalfenster geöffnet, damit Logs von ot-daemon angezeigt werden können.
Verwenden Sie ot-ctl, um mit dem RCP-Knoten zu kommunizieren. ot-ctl verwendet dieselbe CLI wie die OpenThread-CLI-App. Daher können Sie ot-daemon-Knoten auf dieselbe Weise wie die anderen simulierten Thread-Geräte steuern.
Starten Sie ot-ctl in einem zweiten Terminalfenster:
$ sudo ./build/posix/src/posix/ot-ctl >
Prüfen Sie die state von Knoten 2 (dem RCP-Knoten), den Sie mit ot-daemon gestartet haben:
> state disabled Done
5. FTDs einrichten
Die beiden anderen in diesem Codelab verwendeten Thread-Knoten sind Full Thread Devices (FTDs) auf dem Standard-System-on-Chip-Design (SoC). Ein Gerät fungiert als Commissioner, um Geräte in diesem Netzwerk sicher zu authentifizieren und in Betrieb zu nehmen. Das andere Gerät fungiert als Joiner, den der Commissioner für das Thread-Netzwerk authentifizieren kann.
Erstellen und flashen
Erstellen Sie das OpenThread FTD-Beispiel für die nRF52840-Plattform mit aktivierten Commissioner- und Joiner-Rollen:
$ cd ~/src/ot-nrf528xx $ rm -rf build $ script/build nrf52840 USB_trans -DOT_JOINER=ON -DOT_COMMISSIONER=ON
Wechseln Sie zum Verzeichnis mit der binären Datei der OpenThread FTD-CLI (Full Thread Device) und konvertieren Sie sie in das Hexadezimalformat:
$ cd ~/src/ot-nrf528xx/build/bin $ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex
Schließen Sie das USB-Kabel an den Micro-USB-Anschluss neben dem externen Stromanschluss auf dem nRF52840-Board an und verbinden Sie es dann mit dem Linux-Computer. Wenn das RCP noch an den Linux-Computer angeschlossen ist, sollte das neue Board als serieller Port /dev/ttyACM1 angezeigt werden. Alle nRF52840-Boards verwenden ttyACM als Kennung für den seriellen Port.
$ ls /dev/ttyACM* /dev/ttyACM0 /dev/ttyACM1
Notieren Sie sich wie zuvor die Seriennummer des für die FTD verwendeten nRF52840-Boards:
Rufen Sie den Speicherort der nRFx Command Line Tools auf und flashen Sie die OpenThread CLI FTD-Hex-Datei auf das nRF52840-Board. Verwenden Sie dazu die Seriennummer des Boards:
$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
~/src/ot-nrf528xx/build/bin/ot-cli-ftd.hex --reset
Geben Sie dem Board den Namen „Commissioner“.
Mit nativem USB verbinden
Da der OpenThread FTD-Build die Verwendung von nativem USB CDC ACM als seriellen Transport ermöglicht, müssen Sie den nRF USB-Port auf dem nRF52840-Board verwenden, um mit dem RCP-Host (Linux-Computer) zu kommunizieren.
Trennen Sie das Micro-USB-Ende des USB-Kabels vom Debug-Port des geflashten nRF52840-Boards und schließen Sie es dann wieder an den Micro-USB-Port nRF USB neben der RESET-Taste an. Stellen Sie den Schalter nRF power source auf USB.
Build überprüfen
Prüfen Sie, ob der Build erfolgreich war, indem Sie über ein Terminalfenster mit GNU Screen auf die OpenThread-CLI zugreifen.
$ screen /dev/ttyACM1
Drücken Sie im neuen Fenster einige Male die Eingabetaste, um den OpenThread-CLI-Prompt > aufzurufen. Rufen Sie die IPv6-Schnittstelle auf und prüfen Sie, ob Adressen vorhanden sind:
> ifconfig up Done > ipaddr fe80:0:0:0:1cd6:87a9:cb9d:4b1d Done
Strg+A verwenden →
d um die Verbindung zur FTD Commissioner CLI zu trennen und zum Linux-Terminal zurückzukehren, damit das nächste Board geflasht werden kann. Wenn Sie die CLI jederzeit wieder aufrufen möchten, verwenden Sie screen -r in der Befehlszeile. Mit screen -ls können Sie eine Liste der verfügbaren Bildschirme aufrufen:
$ screen -ls
There is a screen on:
74182.ttys000.mylinuxmachine (Detached)
1 Socket in /tmp/uscreens/S-username.
FTD Joiner einrichten
Wiederholen Sie den obigen Vorgang, um das dritte nRF52840-Board mit dem vorhandenen ot-cli-ftd.hex-Build zu flashen. Verbinden Sie die Platine anschließend wieder über den nRF-USB-Anschluss mit dem PC und stellen Sie den Schalter nRF power source auf VDD.
Wenn die anderen beiden Knoten an den Linux-Computer angeschlossen sind, wenn diese dritte Platine angeschlossen wird, sollte sie als serieller Port /dev/ttyACM2 angezeigt werden:
$ ls /dev/ttyACM* /dev/ttyACM0 /dev/ttyACM1 /dev/ttyACM2
Geben Sie dem Board den Namen „Joiner“.
Wenn Sie die Überprüfung mit Screen durchführen, erstellen Sie keine neue Instanz von Screen über die Befehlszeile, sondern stellen Sie die Verbindung zur vorhandenen Instanz wieder her und erstellen Sie darin ein neues Fenster (das Sie für den FTD Commissioner verwendet haben):
$ screen -r
Neues Fenster in Screen erstellen: Strg + a → c.
Eine neue Eingabeaufforderung wird angezeigt. Greifen Sie auf die OpenThread-Befehlszeile für den FTD-Joiner zu:
$ screen /dev/ttyACM2
Drücken Sie in diesem neuen Fenster einige Male die Eingabetaste, um den >-Prompt der OpenThread-Befehlszeile aufzurufen. Rufen Sie die IPv6-Schnittstelle auf und prüfen Sie, ob Adressen vorhanden sind:
> ifconfig up Done > ipaddr fe80:0:0:0:6c1e:87a2:df05:c240 Done
Da sich die FTD Joiner-Befehlszeile jetzt in derselben Screen-Instanz wie der FTD Commissioner befindet, können Sie mit Strg+a → n zwischen den beiden wechseln.
Strg+A verwenden →
d um den Screen zu verlassen.
6. Terminalfenster einrichten
Künftig werden Sie häufig zwischen Thread-Geräten wechseln. Achten Sie daher darauf, dass alle Geräte aktiv und leicht zugänglich sind. Bisher haben wir über „Screen“ auf die beiden FTDs zugegriffen. Mit diesem Tool ist auch der Splitscreen-Modus im selben Terminalfenster möglich. So können Sie sehen, wie ein Knoten auf Befehle reagiert, die auf einem anderen Knoten ausgegeben werden.
Idealerweise sollten Sie vier Fenster zur Verfügung haben:
ot-daemon-Dienst / Protokolle- RCP Joiner über
ot-ctl - FTD-Commissioner über die OpenThread-Befehlszeile
- FTD-Joiner über die OpenThread-Befehlszeile
Wenn Sie Ihr eigenes Terminal bzw. Ihre eigene Konfiguration für den seriellen Port oder Ihr eigenes Tool verwenden möchten, können Sie mit dem nächsten Schritt fortfahren. Konfigurieren Sie die Terminalfenster für alle Geräte so, wie es für Sie am besten passt.
Bildschirm verwenden
Der Einfachheit halber sollten Sie nur eine Screen-Sitzung starten. Sie sollten bereits eines haben, da Sie beide FTDs eingerichtet haben.
Alle Befehle in Screen beginnen mit Strg + a.
Grundlegende Bildschirmbefehle:
Wiederverbinden mit der Screen-Sitzung (über die Befehlszeile) |
|
Screen-Sitzung verlassen | Strg+A → |
Neues Fenster in der Screen-Sitzung erstellen | Strg+A → |
Zwischen Fenstern in derselben Screen-Sitzung wechseln | Strg+A → |
Aktuelles Fenster in der Screen-Sitzung schließen | Strg+A → |
Splitscreen
Mit Screen können Sie das Terminal in mehrere Fenster aufteilen:
Auf Befehle in screen wird mit Strg+a zugegriffen. Jeder Befehl sollte mit dieser Tastenkombination beginnen.
Wenn Sie dem Codelab genau gefolgt sind, sollten Sie zwei Fenster (FTD Commissioner, FTD Joiner) auf derselben Bildschirminstanz haben. Wenn Sie den Bildschirm zwischen den beiden aufteilen möchten, rufen Sie zuerst Ihre bestehende Screen-Sitzung auf:
$ screen -r
Sie sollten sich auf einem der FTD-Geräte befinden. Gehen Sie in Screen so vor:
- Strg + a →
S, um das Fenster horizontal zu teilen - Strg + A →
Tab, um den Cursor in das neue leere Fenster zu verschieben - Strg + A →
n, um das neue Fenster zum nächsten zu wechseln - Wenn es dasselbe wie das obere Fenster ist, drücken Sie noch einmal Strg + A →
n, um das andere FTD-Gerät aufzurufen.
Beide sind jetzt sichtbar. Mit Strg + a → Tab können Sie zwischen den beiden wechseln. Es wird empfohlen, jedes Fenster mit Strg + A → A umzubenennen, um Verwirrung zu vermeiden.
Erweiterte Nutzung
Wenn Sie den Bildschirm weiter in Quadranten aufteilen und die ot-daemon-Logs und den RCP-Joiner ot-ctl aufrufen möchten, müssen diese Dienste in derselben Bildschirminstanz gestartet werden. Beenden Sie dazu ot-daemon und ot-ctl und starten Sie sie in neuen Screen-Fenstern neu (Strg+a → c).
Diese Einrichtung ist nicht erforderlich und wird dem Nutzer überlassen.
Mit den folgenden Befehlen können Sie Fenster aufteilen und zwischen ihnen wechseln:
Neues Fenster erstellen | Strg+A → |
Fenster vertikal teilen | Strg + A → |
Fenster horizontal teilen | Strg+A → |
Zum nächsten angezeigten Fenster wechseln | Strg+A → |
Das angezeigte Fenster vor- oder zurückschalten | Strg + A → |
Aktuelles Fenster umbenennen | Strg+A → |
Sie können Screen jederzeit mit Strg + A → d verlassen und mit screen -r über die Befehlszeile wieder anhängen.
Weitere Informationen zu Screen finden Sie in der GNU Screen-Kurzübersicht.
7. Thread-Netzwerk erstellen
Nachdem Sie alle Terminalfenster und Bildschirme konfiguriert haben, erstellen wir nun unser Thread-Netzwerk. Erstellen Sie auf dem FTD Commissioner ein neues Operational Dataset und legen Sie es als aktives Dataset fest. Das operative Dataset ist die Konfiguration für das Thread-Netzwerk, das Sie erstellen.
## 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
Notiere dir den Netzwerkschlüssel 1234c0de7ab51234c0de7ab51234c0de, der später verwendet wird.
Übernehmen Sie dieses Dataset als das aktive:
> dataset commit active Done
IPv6-Schnittstelle aktivieren:
> ifconfig up Done
Thread-Protokollvorgang starten:
> thread start Done
Prüfe nach einem Moment den Gerätestatus. Es sollte der Leiter sein. Notieren Sie sich auch die RLOC16 für die Zukunft.
## FTD Commissioner ## ---------------------- > state leader Done > rloc16 0c00 Done
Prüfen Sie die IPv6-Adressen des Geräts:
## 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)
Das Netzwerk „codelab“ ist jetzt sichtbar, wenn es von anderen Thread-Geräten gescannt wird.
Über ot-ctl auf der Seite RCP Joiner:
## RCP Joiner ## ---------------- > scan | PAN | MAC Address | Ch | dBm | LQI | +------+------------------+----+-----+-----+ | c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |
Über die OpenThread-Befehlszeile auf dem FTD-Joiner:
## FTD Joiner ## ---------------- > scan | PAN | MAC Address | Ch | dBm | LQI | +------+------------------+----+-----+-----+ | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |
Wenn das Netzwerk „codelab“ nicht in der Liste angezeigt wird, versuchen Sie es noch einmal.
8. RCP Joiner hinzufügen
Die Thread-Inbetriebnahme ist im Netzwerk nicht aktiv. Daher müssen wir den RCP-Joiner dem Thread-Netzwerk, das wir gerade erstellt haben, über einen Out-of-Band-Inbetriebnahmeprozess hinzufügen.
Auf dem FTD Commissioner haben wir uns den Netzwerkschlüssel notiert, z. B. 1234c0de7ab51234c0de7ab51234c0de. Wenn Sie den Netzwerkschlüssel noch einmal nachschlagen müssen, führen Sie den folgenden Befehl auf dem FTD-Commissioner aus:
## FTD Commissioner ## > dataset networkkey 1234c0de7ab51234c0de7ab51234c0de Done
Legen Sie als Nächstes auf dem RCP-Joiner den aktiven Dataset-Netzwerkschlüssel auf den FTD-Commissioner-Netzwerkschlüssel fest:
## RCP Joiner ## ---------------- > dataset networkkey 1234c0de7ab51234c0de7ab51234c0de Done > dataset commit active Done
Prüfen Sie, ob das Dataset richtig festgelegt ist.
## RCP Joiner ## ---------------- > dataset Network Key: 1234c0de7ab51234c0de7ab51234c0de
Stellen Sie Thread so ein, dass der RCP-Joiner dem Netzwerk „codelab“ beitritt. Warten Sie einige Sekunden und prüfen Sie dann den Status, RLOC16 und die IPv6-Adressen:
## 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
Notiere dir die Mesh-lokale IPv6-Adresse (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f). Du benötigst sie später.
Prüfen Sie auf dem FTD-Commissioner in den Router- und untergeordneten Tabellen, ob beide Geräte Teil desselben Netzwerks sind. Verwenden Sie den RLOC16, um den RCP-Joiner zu identifizieren.
## 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
Pinge die Mesh-Local-Adresse des RCP-Joiners (die Mesh-Local-Adresse aus der ipaddr-Ausgabe des RCP-Joiners), um die Verbindung zu prüfen:
## 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
Wir haben jetzt ein Thread-Netzwerk mit zwei Knoten, wie in diesem Topologiediagramm dargestellt:
Topologiediagramme
Im weiteren Verlauf des Codelabs wird immer dann ein neues Thread-Topologiediagramm angezeigt, wenn sich der Status des Netzwerks ändert. Knotenrollen werden so angegeben:
Router sind immer Fünfecke und Endgeräte immer Kreise. Die Zahlen auf jedem Knoten stellen die Router-ID oder die untergeordnete ID dar, die in der CLI-Ausgabe angezeigt wird, je nach aktueller Rolle und aktuellem Status des jeweiligen Knotens zu diesem Zeitpunkt.
9. FTD Joiner in Betrieb nehmen
Fügen wir dem Netzwerk „codelab“ nun das dritte Thread-Gerät hinzu. Dieses Mal verwenden wir das sicherere In-Band-Verfahren und lassen nur den FTD-Joiner zu.
Rufen Sie auf dem FTD Joiner die eui64 ab, damit der FTD-Commissioner sie identifizieren kann:
## FTD Joiner ## ---------------- > eui64 2f57d222545271f1 Done
Starten Sie auf dem FTD-Commissioner den Commissioner und geben Sie die eui64 des Geräts an, das beitreten kann, sowie die Joiner-Anmeldedaten, z. B. J01NME. Das Joiner-Anmeldedaten sind ein gerätespezifischer String aus alphanumerischen Zeichen in Großbuchstaben (0–9 und A–Y, ohne I, O, Q und Z zur besseren Lesbarkeit) mit einer Länge zwischen 6 und 32 Zeichen.
## FTD Commissioner ## ---------------------- > commissioner start Done > commissioner joiner add 2f57d222545271f1 J01NME Done
Wechseln Sie zum FTD Joiner. Starten Sie die Joiner-Rolle mit den Joiner-Anmeldedaten, die Sie gerade auf dem FTD-Commissioner eingerichtet haben:
## FTD Joiner ## ---------------- > ifconfig up Done > joiner start J01NME Done
Innerhalb einer Minute erhalten Sie eine Bestätigung der erfolgreichen Authentifizierung:
## FTD Joiner ## ---------------- > Join success
Starte Thread, damit der FTD-Joiner dem Netzwerk „codelab“ beitritt, und prüfe sofort den Status und RLOC16:
## FTD Joiner ## ---------------- > thread start Done > state child Done > rloc16 0c02 Done
Prüfen Sie die IPv6-Adressen des Geräts. Beachten Sie, dass es keine ALOC gibt. Das liegt daran, dass dieses Gerät nicht das Leader ist und auch keine Anycast-spezifische Rolle hat, für die ein ALOC erforderlich ist.
## 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)
Wechsle sofort zum FTD Commissioner und prüfe die Router- und untergeordneten Tabellen, um zu bestätigen, dass im Netzwerk „codelab“ drei Geräte vorhanden sind:
## 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
Anhand des RLOC16 hat sich der FTD-Joiner als Endgerät (untergeordnetes Gerät) mit dem Netzwerk verbunden. Hier ist unsere aktualisierte Topologie:
10. Unterhaltung in Aktion
Die Thread-Geräte in diesem Codelab sind eine spezielle Art von Full Thread Device (FTD), die als Router Eligible End Device (REED) bezeichnet wird. Das bedeutet, dass sie entweder als Router oder als Endgerät fungieren und sich von einem Endgerät zu einem Router hochstufen können.
Thread kann bis zu 32 Router unterstützen, versucht aber, die Anzahl der Router zwischen 16 und 23 zu halten. Wenn ein REED als Endgerät (untergeordnetes Gerät) verbunden wird und die Anzahl der Router unter 16 liegt, wird es nach einem zufälligen Zeitraum von maximal zwei Minuten automatisch zum Router hochgestuft.
Wenn Sie nach dem Hinzufügen des FTD-Joiners zwei untergeordnete Geräte in Ihrem Thread-Netzwerk hatten, warten Sie mindestens zwei Minuten und prüfen Sie dann die Router- und untergeordneten Tabellen auf dem FTD-Commissioner noch einmal:
## 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
Der FTD-Joiner (erweiterte MAC-Adresse = e6cdd2d93249a243) hat sich selbst zum Router hochgestuft. Beachten Sie, dass sich der RLOC16 unterscheidet (b800 statt 0c02). Das liegt daran, dass der RLOC16 auf der Router-ID und der untergeordneten ID eines Geräts basiert. Wenn das Gerät vom Endgerät zum Router wechselt, ändern sich die Werte für Router-ID und untergeordnete ID sowie die RLOC16.
Bestätigen Sie den neuen Status und RLOC16 auf dem FTD-Joiner:
## FTD Joiner ## ---------------- > state router Done > rloc16 b800 Done
Downgrade des FTD Joiner
Sie können dieses Verhalten testen, indem Sie den FTD-Joiner manuell von einem Router auf ein Endgerät downgraden. Ändern Sie den Status in „child“ und prüfen Sie den RLOC16:
## FTD Joiner ## ---------------- > state child Done > rloc16 0c03 Done
Zurück auf dem FTD Commissioner sollte der FTD-Joiner jetzt in der untergeordneten Tabelle (ID = 3) angezeigt werden. Möglicherweise ist sie während der Umstellung sogar in beiden Apps verfügbar:
## 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
Nach einiger Zeit wird wieder ein Router mit dem RLOC b800 verwendet.
Führungsperson entfernen
Der Leader wird von allen Thread-Routern selbst ausgewählt. Wenn der aktuelle Leader aus dem Thread-Netzwerk entfernt wird, wird einer der anderen Router zum neuen Leader.
Schalte auf dem FTD-Commissioner Thread aus, um ihn aus dem Thread-Netzwerk zu entfernen:
## FTD Commissioner ## ---------------------- > thread stop Done > ifconfig down Done
Innerhalb von zwei Minuten wird der FTD Joiner zum neuen Thread-Leader. Prüfen Sie den Status und die IPv6-Adressen des FTD-Joiners, um Folgendes zu bestätigen:
## 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
Prüfen Sie die untergeordnete Tabelle. Beachten Sie, dass es einen neuen RLOC16 gibt. Dies ist der RCP-Joiner, wie durch seine ID und erweiterte MAC-Adresse angegeben. Damit das Thread-Netzwerk zusammenbleibt, hat er den übergeordneten Router gewechselt, vom FTD-Commissioner zum FTD-Joiner. Dies führt zu einem neuen RLOC16 für den RCP-Joiner, da sich seine Router-ID von 3 zu 46 geändert hat.
## 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
Es kann einige Minuten dauern, bis das RCP Joiner als untergeordnetes Element an das FTD Joiner angehängt wird. Prüfen Sie den Status und den RLOC16, um Folgendes zu bestätigen:
## RCP Joiner ## -------------- > state child > rloc16 b801
FTD Commissioner wieder anbringen
Ein Thread-Netzwerk mit zwei Knoten ist nicht sehr nützlich. Wir bringen den FTD Commissioner wieder online.
Starte Thread auf dem FTD-Commissioner neu:
## FTD Commissioner ## ---------------------- > ifconfig up Done > thread start Done
Innerhalb von zwei Minuten wird es automatisch wieder als Endgerät mit dem Netzwerk „codelab“ verbunden und dann zum Router hochgestuft.
## FTD Commissioner ## ---------------------- > state router Done
Prüfen Sie die Router- und untergeordneten Tabellen auf dem FTD Joiner, um Folgendes zu überprüfen:
## 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
Unser Thread-Netzwerk besteht wieder aus drei Knoten.
11. Fehlerbehebung
Die Verwaltung eines Thread-Netzwerks mit mehreren Geräten in verschiedenen Terminal- oder Bildschirmfenstern kann kompliziert sein. Mit diesen Tipps können Sie den Status des Netzwerks oder Ihres Arbeitsbereichs zurücksetzen, wenn Probleme auftreten.
Bildschirm
Wenn Sie sich in Ihrer Konfiguration verirren (zu viele Screen-Fenster oder Screens in Screen), beenden Sie Screen-Fenster mit Strg+a → k, bis keine mehr vorhanden sind und screen -ls in der Befehlszeile No Sockets found ausgibt. Erstellen Sie dann für jedes Gerät Bildschirmfenster neu. Gerätestatus wird beibehalten, auch wenn der Bildschirm geschlossen wird.
Thread-Knoten
Wenn die Thread-Netzwerktopologie nicht wie in diesem Codelab beschrieben ist oder Knoten aus irgendeinem Grund getrennt werden (vielleicht, weil der Linux-Computer, auf dem sie ausgeführt werden, in den Ruhemodus gewechselt ist), ist es am besten, Thread zu beenden, die Netzwerkanmeldedaten zu löschen und mit dem Schritt Thread-Netzwerk erstellen neu zu beginnen.
So setzen Sie die FTDs zurück:
## FTD Commissioner or FTD Joiner ## ------------------------------------ > thread stop Done > ifconfig down Done > factoryreset Done
Der RCP kann auf dieselbe Weise über ot-ctl zurückgesetzt werden:
## RCP Joiner ## ---------------- > thread stop Done > ifconfig down Done > factoryreset Done
12. Multicast verwenden
Multicast wird verwendet, um Informationen gleichzeitig an eine Gruppe von Geräten zu senden. In einem Thread-Netzwerk sind bestimmte Adressen für die Multicast-Verwendung mit verschiedenen Gerätegruppen reserviert, je nach Bereich.
IPv6-Adresse | Ebene | Geliefert an |
| Link-Local | Alle FTDs und MEDs |
| Link-Local | Alle FTDs und Border-Router |
| Mesh-Local | Alle FTDs und MEDs |
| Mesh-Local | Alle FTDs und Border-Router |
Da wir in diesem Codelab keinen Border Router verwenden, konzentrieren wir uns auf die beiden Multicast-Adressen für FTD und MED.
Link-Local
Der Link-Local-Bereich umfasst alle Thread-Schnittstellen, die durch eine einzelne Funkübertragung oder einen einzelnen „Hop“ erreichbar sind. Die Netzwerktopologie bestimmt, welche Geräte auf einen Ping an die Multicast-Adresse ff02::1 reagieren.
Pingen Sie ff02::1 über den FTD Commissioner an:
## FTD Commissioner ## ---------------------- > ping ff02::1 > 8 bytes from fe80:0:0:0:e4cd:d2d9:3249:a243: icmp_seq=2 hlim=64 time=9ms
Es gibt zwei weitere Geräte im Netzwerk (FTD Joiner und RCP Joiner), aber der FTD Commissioner hat nur eine Antwort von der Link-Local-Adresse (LLA) des FTD Joiner erhalten. Das bedeutet, dass der FTD-Joiner das einzige Gerät ist, das der FTD-Commissioner mit einem einzigen Hop erreichen kann.
Pinge jetzt ff02::1 über den 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
Zwei Antworten! Wenn wir die IPv6-Adressen der anderen Geräte prüfen, sehen wir, dass die erste (mit 4b1d) die LLA des FTD-Commissioners und die zweite (mit 943b) die LLA des RCP-Joiners ist.
Das bedeutet, dass der FTD-Joiner direkt mit dem FTD-Commissioner und dem RCP-Joiner verbunden ist, was unsere Topologie bestätigt.
Mesh-Local
Der Mesh-Local-Bereich umfasst alle Thread-Schnittstellen, die im selben Thread-Netzwerk erreichbar sind. Sehen wir uns die Antworten auf einen Ping an die Multicast-Adresse ff03::1 an.
Pingen Sie ff03::1 über den FTD Commissioner an:
## 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
Dieses Mal hat der FTD-Commissioner zwei Antworten erhalten: eine vom Routing Locator (RLOC) des FTD-Joiners (endet mit b800) und eine von der Mesh-Local EID (ML-EID) des RCP-Joiners (endet mit d55f). Das liegt daran, dass der Mesh-Local-Bereich das gesamte Thread-Netzwerk umfasst. Unabhängig davon, wo sich ein Gerät im Netzwerk befindet, ist es für die ff03::1-Adresse registriert.
Pinge ff03::1 vom FTD Joiner an, um das gleiche Verhalten zu bestätigen:
## 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
Notieren Sie sich die Antwortzeit für den RCP-Joiner in beiden Ping-Ausgaben. Es hat viel länger gedauert, bis der RCP-Joiner den FTD-Commissioner (68 ms) erreicht hat, als bis er den FTD-Joiner (23 ms) erreicht hat. Das liegt daran, dass es zwei Hops benötigt, um den FTD-Commissioner zu erreichen, während der FTD-Joiner nur einen Hop benötigt.
Möglicherweise haben Sie auch bemerkt, dass der Mesh-lokale Multicast-Ping nur für die beiden FTDs mit dem RLOC beantwortet wurde, nicht für den RCP-Joiner. Das liegt daran, dass die FTDs Router im Netzwerk sind, während der RCP ein Endgerät ist.
Prüfe den Status von RCP Joiner, um dies zu bestätigen:
## RCP Joiner ## ---------------- > state child
13. Nachrichten mit UDP senden
Einer der Anwendungsdienste, die OpenThread bietet, ist das User Datagram Protocol (UDP), ein Protokoll der Transportschicht. Eine auf OpenThread basierende Anwendung kann die UDP API verwenden, um Nachrichten zwischen Knoten in einem Thread-Netzwerk oder an andere Geräte in einem externen Netzwerk (z. B. im Internet, wenn das Thread-Netzwerk einen Border Router hat) zu senden.
UDP-Sockets werden über die OpenThread-Befehlszeile bereitgestellt. Wir verwenden sie, um Nachrichten zwischen den beiden FTDs zu übergeben.
Rufen Sie die Mesh-Local EID-Adresse für den FTD-Joiner ab. Wir verwenden diese Adresse, weil sie von überall im Thread-Netzwerk erreichbar ist.
## 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
Starten Sie UDP und binden Sie es an einen Socket für eine beliebige IPv6-Adresse:
## FTD Joiner ## ---------------- > udp open Done > udp bind :: 1212
Wechsle zum FTD Commissioner, starte UDP und stelle mit der ML-EID eine Verbindung zum Socket her, den du auf dem FTD Joiner eingerichtet hast:
## FTD Commissioner ## ---------------------- > udp open Done > udp connect fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd 1212 Done
Die UDP-Verbindung sollte zwischen den beiden Knoten aktiv sein. Nachricht vom FTD Commissioner senden:
## FTD Commissioner ## ---------------------- > udp send hellothere Done
Die UDP-Nachricht wurde auf dem FTD-Joiner empfangen.
## FTD Joiner ## ---------------- > 10 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00 49153 hellothere
14. Glückwunsch!
Du hast ein physisches Thread-Netzwerk erstellt.
Sie wissen jetzt:
- Unterschiede zwischen Thread-Gerätetypen, ‑Rollen und ‑Bereichen
- wie Thread-Geräte ihre Status im Netzwerk verwalten
- Einfache Nachrichten zwischen Knoten über UDP übergeben
Nächste Schritte
Versuchen Sie, die folgenden Übungen zu absolvieren:
- Flashen Sie das FTD-Joiner-Board mit der Binärdatei
ot-cli-mtdals MTD neu und beobachten Sie, dass es sich nie auf einen Router aktualisiert oder versucht, der Leader zu werden. - Fügen Sie dem Netzwerk weitere Geräte hinzu (probieren Sie eine andere Plattform aus!) und skizzieren Sie die Topologie mithilfe von Router- und untergeordneten Tabellen sowie Pings an die Multicast-Adressen.
- pyspinel zur Steuerung des NCP verwenden
- NCP mit OpenThread Border Router in einen Border-Router umwandeln und das Thread-Netzwerk mit dem Internet verbinden
Weitere Informationen
Auf openthread.io und GitHub finden Sie verschiedene OpenThread-Ressourcen, darunter:
- Unterstützte Plattformen: Hier finden Sie alle Plattformen, die OpenThread unterstützen.
- OpenThread erstellen – Weitere Informationen zum Erstellen und Konfigurieren von OpenThread
- Thread-Grundlagen: Hier werden alle Thread-Konzepte behandelt, die in diesem Codelab vorgestellt werden.
Referenz: