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 für Entwickler allgemein verfügbar zu machen 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 drahtloses Protokoll für die Kommunikation zwischen Geräten für Anwendungen im Zuhause. OpenThread implementiert alle Thread-Netzwerkschichten, einschließlich IPv6, 6LoWPAN, IEEE 802.15.4 mit MAC-Sicherheit, Mesh-Link-Einrichtung 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-CLI-Binärdateien auf Entwicklungsboards erstellen und flashen
- RCP aus einem Linux-Computer und einem Entwicklungsboard erstellen
- Kommunikation mit einem RCP über OpenThread-Daemon und
ot-ctl - Thread-Knoten manuell mit GNU Screen und der OpenThread-Befehlszeile verwalten
- Sichere Inbetriebnahme von Geräten in einem Thread-Netzwerk
- So funktioniert IPv6-Multicast
- Nachrichten zwischen Threadknoten mit UDP übergeben
Voraussetzungen
Hardware:
- 3 Entwicklerboards nRF52840 von Nordic Semiconductor
- 3 USB-auf-Micro-USB-Kabel zum Verbinden der Boards
- Einen Linux-Computer mit mindestens drei USB-Anschlüssen
Software:
- GNU-Toolchain
- Befehlszeilentools für Nordic nRF5x
- Segger J-Link-Software
- OpenThread
- Git
2. Erste Schritte
OpenThread-Simulation
Bevor Sie beginnen, sollten Sie das OpenThread Simulation Codelab durchgehen, um sich mit den grundlegenden Thread-Konzepten und der OpenThread-Befehlszeile vertraut zu machen.
Serielle Terminals
Sie sollten wissen, wie Sie über ein Terminal eine Verbindung zu einem seriellen Port herstellen. In diesem Codelab wird GNU Screen verwendet und es wird eine Übersicht über die Verwendung gegeben. Sie können aber auch jede andere Terminalsoftware verwenden.
Linux-Rechner
Dieses Codelab wurde für die Verwendung eines i386- oder x86-basierten Linux-Rechners entwickelt, der als Host für ein RCP-Thread-Gerät (Radio Co-Processor) dient und alle Thread-Entwicklungsboards flasht. 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 es 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-Befehlszeilentools können Sie die OpenThread-Binärdateien auf die nRF52840-Boards flashen. Installieren Sie die entsprechende Build-Version von nRF5x-Command-Line-Tools-<OS> auf Ihrem Linux-Computer.
Verschieben Sie das extrahierte Paket in den Stammordner ~/.
ARM GNU Toolchain installieren
Für den Build wird die ARM GNU Toolchain verwendet.
Wir empfehlen, das extrahierte Archiv auf Ihrem Linux-Computer unter /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/ zu platzieren. Folgen Sie der Installationsanleitung in der Datei readme.txt des Archivs.
Installationsbildschirm (optional)
Screen ist ein einfaches Tool, mit dem Sie auf Geräte zugreifen können, die über einen seriellen Port verbunden sind. In diesem Codelab wird Screen verwendet, Sie können aber jede beliebige Terminalanwendung für den seriellen Port verwenden.
$ sudo apt-get install screen
3. Repositories klonen
OpenThread
Klonen und installieren Sie OpenThread. 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 kompilieren und auf die nRF52840-Boards flashen.
4. RCP-Joiner einrichten
Build und Flash
Erstellen Sie das OpenThread-Beispiel für nRF52840 mit Joiner und nativer USB-Funktion. Ein Gerät verwendet die Rolle „Teilnehmer“, um sich sicher zu authentifizieren und in einem Thread-Netzwerk in Betrieb zu nehmen. Natives 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
Rufen Sie das Verzeichnis mit der OpenThread-RCP-Binärdatei auf und konvertieren Sie sie 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-Port neben dem externen Stromversorgungsanschluss auf dem nRF52840-Board an und dann an den Linux-Computer. Stellen Sie den Schalter für die nRF-Stromversorgung auf dem nRF52840-Board auf VDD. Wenn die Verbindung richtig hergestellt ist, leuchtet LED5.
Wenn dies das erste Board ist, das an den Linux-Computer angeschlossen ist, wird es als serielle Schnittstelle /dev/ttyACM0 angezeigt. Alle nRF52840-Boards verwenden ttyACM als serielle Port-ID.
$ ls /dev/ttyACM* /dev/ttyACM0
Notieren Sie sich die Seriennummer des nRF52840-Boards, das für das RCP verwendet wird:
Rufen Sie den Speicherort der nRFx-Befehlszeilentools auf und flashen Sie die OpenThread-RCP-Hexdatei mit der Seriennummer des Boards auf das nRF52840-Board. 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.
Beschriften Sie das Board mit „RCP“, damit Sie die Rollen 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 Taste RESET an. Stellen Sie den Schalter für die nRF-Stromquelle 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 -v-Flag für ausführliche Ausgabe, damit Sie die Protokollausgabe sehen und prüfen können, ob das Programm ausgeführt wird:
$ cd ~/src/openthread
$ sudo ./build/posix/src/posix/ot-daemon -v \
'spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=460800'
Bei Erfolg generiert ot-daemon im ausführlichen Modus eine Ausgabe, die in etwa so aussieht:
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 Befehlszeile wie die OpenThread CLI App. Daher können Sie ot-daemon-Knoten auf die gleiche Weise wie andere simulierte Thread-Geräte steuern.
Starten Sie in einem zweiten Terminalfenster ot-ctl:
$ 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 Thread-Knoten in diesem Codelab sind Full Thread Devices (FTDs) mit dem Standard-SoC-Design (System-on-Chip). In einer Produktionsumgebung kann wpantund, ein Netzwerk-Interface-Treiber für die Produktion, verwendet werden, um OpenThread-NCP-Instanzen zu steuern. In diesem Codelab verwenden wir jedoch ot-ctl, die OpenThread-Befehlszeile.
Ein Gerät fungiert als Instanziierungsstelle, um Geräte sicher zu authentifizieren und in diesem Netzwerk in Betrieb zu nehmen. Das andere Gerät dient als Joiner, über den sich der Bevollmächtigte beim Thread-Netzwerk authentifizieren kann.
Build und Flash
Erstellen Sie das OpenThread-FTD-Beispiel für die nRF52840-Plattform mit aktivierten Rollen „Commissioner“ und „Joiner“:
$ cd ~/src/ot-nrf528xx $ rm -rf build $ script/build nrf52840 USB_trans -DOT_JOINER=ON -DOT_COMMISSIONER=ON
Rufen Sie das Verzeichnis mit der OpenThread-FTD-CLI-Binärdatei auf 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 dann an den Linux-Computer. Wenn das RCP noch mit dem Linux-Computer verbunden ist, sollte dieses neue Board als serieller Port /dev/ttyACM1 angezeigt werden. Alle nRF52840-Boards verwenden ttyACM als serielle Port-ID.
$ ls /dev/ttyACM* /dev/ttyACM0 /dev/ttyACM1
Notieren Sie sich wie zuvor die Seriennummer des nRF52840-Boards, das für die FTD verwendet wird:
Rufen Sie den Speicherort der nRFx-Befehlszeilentools auf und flashen Sie die OpenThread-CLI-FTD-Hexdatei mit der Seriennummer des Boards auf das nRF52840-Board:
$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
~/src/ot-nrf528xx/build/bin/ot-cli-ftd.hex --reset
Beschriften Sie das Board mit „Kommission“.
Mit nativem USB verbinden
Da die OpenThread-FTD-Build-Version 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 Taste RESET an. Stellen Sie den Schalter für die nRF-Stromquelle auf USB.
Build prüfen
Prüfen Sie, ob der Build erfolgreich war, indem Sie über ein Terminalfenster mit GNU Screen auf die OpenThread-Befehlszeile zugreifen.
$ screen /dev/ttyACM1
Drücken Sie im neuen Fenster mehrmals die Eingabetaste, um den OpenThread-Befehlszeilen-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-Befehlszeile zu trennen und zum Linux-Terminal zurückzukehren, damit das nächste Board geflasht werden kann. Wenn Sie die Befehlszeile jederzeit wieder aufrufen möchten, geben Sie in der Befehlszeile screen -r ein. 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. Schließen Sie das Board anschließend über den nRF-USB-Port wieder an den PC an und stellen Sie den Schalter für die nRF-Stromquelle auf VDD.
Wenn die anderen beiden Knoten mit dem Linux-Computer verbunden sind, während dieses dritte Board angeschlossen ist, sollte es als serielle Schnittstelle /dev/ttyACM2 angezeigt werden:
$ ls /dev/ttyACM* /dev/ttyACM0 /dev/ttyACM1 /dev/ttyACM2
Beschriften Sie das Brett mit „Joiner“.
Wenn Sie die Überprüfung mit Screen durchführen, erstellen Sie nicht über die Befehlszeile eine neue Instanz von Screen, sondern verbinden Sie sich wieder mit der vorhandenen Instanz und erstellen Sie darin ein neues Fenster, das Sie für den FTD Commissioner verwendet haben:
$ screen -r
Erstellen Sie ein neues Fenster in Screen mit Strg + a → c.
Eine neue Eingabeaufforderung wird angezeigt. Rufen Sie die OpenThread-Befehlszeile für den FTD-Joiner auf:
$ screen /dev/ttyACM2
Drücken Sie in diesem neuen Fenster mehrmals die Eingabetaste, um den OpenThread-Befehlszeilen-Prompt > 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 Instanz von Screen wie die FTD Commissioner-Befehlszeile befindet, kannst du mit Strg + A → n zwischen ihnen wechseln.
Strg + A verwenden →
Sie können jederzeit die Taste d drücken, um den Bildschirmschoner zu beenden.
6. Terminalfenster einrichten
In Zukunft wechseln Sie häufig zwischen Thread-Geräten. Achten Sie daher darauf, dass alle Geräte aktiv und leicht zugänglich sind. Bisher haben wir Screen verwendet, um auf die beiden FTDs zuzugreifen. Dieses Tool ermöglicht auch den Splitscreen im selben Terminalfenster. So können Sie sehen, wie ein Knoten auf Befehle reagiert, die an einen 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 OpenThread-Befehlszeile
Wenn Sie Ihre eigene Terminal-/Serienportkonfiguration 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 geeignet ist.
Bildschirm verwenden
Starten Sie zur Vereinfachung nur eine Screen-Sitzung. Sie sollten bereits eine haben, die Sie beim Einrichten der beiden FTDs erstellt haben.
Alle Befehle in Screen beginnen mit Strg + A.
Grundlegende Befehle für das Display:
Über die Befehlszeile wieder mit der Screen-Sitzung verbinden |
|
Screen-Sitzung beenden | Strg + A → |
Neues Fenster in der Screen-Sitzung erstellen | Strg + A → |
Zwischen Fenstern in derselben Bildschirmsitzung wechseln | Strg + A → |
Aktuelles Fenster in der Screen-Sitzung beenden | Strg + A → |
Splitscreen
Mit Screen können Sie das Terminal in mehrere Fenster aufteilen:
Mit Strg + A können Sie auf Befehle in screen zugreifen. 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 aufteilen möchten, müssen Sie zuerst Ihre vorhandene Screen-Sitzung aufrufen:
$ screen -r
Sie sollten sich auf einem der FTD-Geräte befinden. Gehen Sie auf dem Bildschirm so vor:
- Strg + A →
S, um das Fenster horizontal zu teilen - Strg + A →
Tab, um den Cursor in das neue leere Fenster zu bewegen - Strg + A →
n, um von diesem neuen Fenster zum nächsten zu wechseln - Wenn es mit dem Fenster oben übereinstimmt, drücken Sie noch einmal Strg + A →
n, um das andere FTD-Gerät aufzurufen.
Sie sind jetzt beide sichtbar. Mit Strg + a → Tab können Sie zwischen ihnen wechseln. Wir empfehlen, jedem Fenster einen neuen Namen zu geben, indem Sie Strg + A → A drücken, um Verwechslungen zu vermeiden.
Erweiterte Nutzung
Wenn Sie den Bildschirm weiter in Quadranten unterteilen und die ot-daemon-Protokolle 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 als Übung überlassen.
Mit den folgenden Befehlen können Sie Fenster teilen und zwischen ihnen wechseln:
Neues Fenster erstellen | Strg + A → |
Fenster vertikal teilen | Strg + A → |
Fenster horizontal teilen | Strg + A → |
Zum nächsten angezeigten Fenster springen | Strg + A → |
Zum nächsten oder vorherigen angezeigten Fenster wechseln | Strg + A → |
Aktuelles Fenster umbenennen | Strg + A → |
Sie können Screen jederzeit mit Strg + a → d verlassen und über die Befehlszeile mit screen -r wieder verbinden.
Weitere Informationen zu Screen finden Sie in der Kurzreferenz für GNU Screen.
7. Thread-Netzwerk erstellen
Nachdem Sie alle Terminalfenster und ‑bildschirme konfiguriert haben, erstellen wir nun unser Thread-Netzwerk. Erstellen Sie im FTD Commissioner einen neuen aktiven Datensatz. Der Betriebsdatensatz 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
Notieren Sie sich den Netzwerkschlüssel 1234c0de7ab51234c0de7ab51234c0de, der später verwendet wird.
Committen Sie diesen Datensatz als aktiven Datensatz:
> dataset commit active Done
Rufen Sie die IPv6-Schnittstelle auf:
> ifconfig up Done
Starten Sie den Thread-Protokollvorgang:
> thread start Done
Prüfen Sie nach einem Moment den Gerätestatus. Es sollte der Leiter sein. Notieren Sie sich auch die RLOC16 für später.
## 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 im 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 noch einmal, zu scannen.
8. RCP-Joiner hinzufügen
Die Thread-Inbetriebnahme ist im Netzwerk nicht aktiv. Das bedeutet, dass wir dem Thread-Netzwerk, das wir gerade erstellt haben, den RCP-Joiner mithilfe eines Out-of-Band-Inbetriebnahmeprozesses hinzufügen müssen.
Auf dem FTD Commissioner haben wir uns den Netzwerkschlüssel notiert, z. B. 1234c0de7ab51234c0de7ab51234c0de. Wenn Sie den Netzwerkschlüssel noch einmal abrufen müssen, führen Sie den folgenden Befehl auf dem FTD Commissioner aus:
## FTD Commissioner ## > dataset networkkey 1234c0de7ab51234c0de7ab51234c0de Done
Legen Sie als Nächstes im RCP Joiner den Netzwerkschlüssel des aktiven Datensatzes auf den Netzwerkschlüssel des FTD-Kommissars fest:
## RCP Joiner ## ---------------- > dataset networkkey 1234c0de7ab51234c0de7ab51234c0de Done > dataset commit active Done
Prüfen Sie, ob der Datensatz richtig eingerichtet ist.
## RCP Joiner ## ---------------- > dataset Network Key: 1234c0de7ab51234c0de7ab51234c0de
Öffnen Sie den Thread, damit der RCP-Joiner dem Netzwerk „codelab“ beitritt. Warten Sie einige Sekunden und prüfen Sie 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
Notieren Sie sich die mesh-lokale IPv6-Adresse (hier fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f). Sie benötigen sie später.
Prüfen Sie in der FTD Commissioner-Benutzeroberfläche in den Router- und untergeordneten Tabellen, ob sich beide Geräte im selben Netzwerk befinden. Verwenden Sie 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
Führen Sie einen Ping auf die Mesh-lokale Adresse des RCP-Joiners aus (die Mesh-lokale Adresse, die aus der ipaddr-Ausgabe des RCP-Joiners abgerufen wurde), 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 jedes Mal, wenn sich der Status des Netzwerks ändert, ein neues Thread-Topologiediagramm angezeigt. Knotenrollen werden folgendermaßen gekennzeichnet:
Router sind immer Fünfecke und Endgeräte immer Kreise. Die Zahlen auf den einzelnen Knoten entsprechen der Router-ID oder untergeordneten ID, die in der Befehlszeilenausgabe angezeigt wird. Dies hängt von der aktuellen Rolle und dem aktuellen Status des jeweiligen Knotens ab.
9. FTD-Joiner in Betrieb nehmen
Fügen wir dem „codelab“-Netzwerk nun das dritte Thread-Gerät hinzu. Dieses Mal verwenden wir den sichereren In-Band-Bereitstellungsprozess und erlauben nur dem FTD-Joiner, beizutreten.
Rufe auf dem FTD Joiner die eui64 ab, damit der FTD-Beauftragte sie identifizieren kann:
## FTD Joiner ## ---------------- > eui64 2f57d222545271f1 Done
Starten Sie den FTD Commissioner und geben Sie die eui64 des Geräts, das beitreten kann, sowie die Anmeldedaten für den Teilnehmer an, z. B. J01NME. Die Anmeldedaten für den Teilnehmer sind ein gerätespezifischer String aus ausschließlich alphanumerischen Großbuchstaben (0–9 und A–Y, ausgenommen I, O, Q und Z aus Gründen der Lesbarkeit) mit einer Länge von 6 bis 32 Zeichen.
## FTD Commissioner ## ---------------------- > commissioner start Done > commissioner joiner add 2f57d222545271f1 J01NME Done
Wechseln Sie zum FTD Joiner. Starte die Rolle „Teilnehmer“ mit den Anmeldedaten für Teilnehmer, die du gerade im FTD Commissioner eingerichtet hast:
## FTD Joiner ## ---------------- > ifconfig up Done > joiner start J01NME Done
Innerhalb einer Minute erhalten Sie eine Bestätigung der erfolgreichen Authentifizierung:
## FTD Joiner ## ---------------- > Join success
Starten Sie Thread, damit der FTD-Joiner dem Netzwerk „codelab“ beitritt, und prüfen Sie 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 der Leader ist und auch keine Anycast-spezifische Rolle hat, für die eine 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)
Wechseln Sie sofort zum FTD Commissioner und prüfen Sie die Router- und untergeordneten Tabellen, um sicherzustellen, dass sich im Netzwerk „codelab“ drei Geräte befinden:
## 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
Basierend auf dem RLOC16 ist der FTD-Joiner als Endgerät (untergeordnet) mit dem Netzwerk verbunden. Hier ist die aktualisierte Topologie:
10. Thread 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 Endgerät fungieren und sich von einem Endgerät zu einem Router hochstufen können.
Thread kann bis zu 32 Router unterstützen, versucht jedoch, die Anzahl der Router zwischen 16 und 23 zu halten. Wenn ein REED als Endgerät (untergeordnet) verbunden ist und die Anzahl der Router unter 16 liegt, wird es nach einem zufälligen Zeitraum innerhalb von zwei Minuten automatisch zu einem Router.
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 noch einmal die Router- und untergeordneten Tabellen auf dem FTD-Kommissär:
## 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 zu einem Router gemacht. Beachten Sie, dass die RLOC16-Adresse unterschiedlich ist (b800 anstelle von 0c02). Das liegt daran, dass die RLOC16-Adresse auf der Router-ID und der untergeordneten ID eines Geräts basiert. Wenn es vom Endgerät zum Router wechselt, ändern sich die Werte für die Router-ID und die 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
FTD Joiner auf eine niedrigere Version zurücksetzen
Sie können dieses Verhalten testen, indem Sie den FTD Joiner manuell von einem Router auf ein Endgerät zurückstufen. Ändern Sie den Status in „untergeordnet“ und prüfen Sie den RLOC16:
## FTD Joiner ## ---------------- > state child Done > rloc16 0c03 Done
Zurück auf der Seite FTD Commissioner sollte der FTD-Teilnehmer jetzt in der untergeordneten Tabelle (ID = 3) angezeigt werden. Während der Umstellung kann es sogar in beiden Konten angezeigt werden:
## 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 wechselt er wieder zu einem Router mit einem RLOC von b800.
Führungsperson entfernen
Der Leader wird von allen Thread-Routern gewählt. Wenn also der aktuelle Leader aus dem Thread-Netzwerk entfernt wird, wird einer der anderen Router zum neuen Leader.
Deaktivieren Sie Thread im FTD Commissioner, 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-Leiter. 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 ein neues RLOC16 gibt. Dies ist der RCP-Joiner, wie seine ID und erweiterte MAC-Adresse zeigen. Um das Thread-Netzwerk zusammenzuhalten, hat er den übergeordneten Router vom FTD-Kommissär zum FTD-Joiner gewechselt. Dies führt zu einem neuen RLOC16 für den RCP-Joiner, da sich seine Router-ID von 3 auf 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 der RCP-Joiner als untergeordnetes Element an den 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-Beauftragten wieder verknüpfen
Ein Thread-Netzwerk mit zwei Knoten ist nicht besonders nützlich. Lassen Sie uns den FTD-Beauftragten wieder online stellen.
Starte den Thread im FTD Commissioner neu:
## FTD Commissioner ## ---------------------- > ifconfig up Done > thread start Done
Innerhalb von zwei Minuten wird es automatisch wieder als Endgerät mit dem „codelab“-Netzwerk verbunden und befördert sich dann selbst zu einem Router.
## FTD Commissioner ## ---------------------- > state router Done
Prüfe die Router- und untergeordneten Tabellen im 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 auf 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 verlaufen (zu viele Screen-Fenster oder Screens in Screens), beenden Sie die Screen-Fenster mit Strg + a → k, bis keine mehr vorhanden sind und screen -ls in der Befehlszeile No Sockets found zurückgibt. Erstellen Sie dann für jedes Gerät neue Bildschirmfenster. Gerätestatus bleiben erhalten, auch wenn der Bildschirm beendet wird.
Thread-Knoten
Wenn die Thread-Netzwerktopologie nicht der in diesem Codelab beschriebenen entspricht oder Knoten aus irgendeinem Grund getrennt werden (z. B. weil der Linux-Computer, der sie steuert, in den Ruhezustand versetzt wurde), sollten Sie Thread beenden, die Netzwerkanmeldedaten löschen und mit dem Schritt Thread-Netzwerk erstellen neu 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 die gleiche 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 je nach Umfang für die Multicast-Nutzung mit verschiedenen Gerätegruppen reserviert.
IPv6-Adresse | Ebene | Geliefert an |
| Link-Local | Alle FTDs und MEDs |
| Link-Local | Alle FTDs und Border-Router |
| Mesh-lokal | Alle FTDs und MEDs |
| Mesh-lokal | Alle FTDs und Border-Router |
Da wir in diesem Codelab keinen Border Router verwenden, konzentrieren wir uns auf die beiden FTD- und MED-Multicast-Adressen.
Link-Local
Der linklokale Bereich umfasst alle Thread-Schnittstellen, die über eine einzelne Funkübertragung oder einen einzelnen „Hop“ erreichbar sind. Die Netzwerktopologie bestimmt, welche Geräte auf einen Ping an die ff02::1-Multicast-Adresse antworten.
Ping ff02::1 vom FTD Commissioner aus:
## 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 Address (LLA) des FTD Joiners erhalten. Das bedeutet, dass der FTD Joiner das einzige Gerät ist, das der FTD Commissioner mit einem einzigen Hop erreichen kann.
Führen Sie jetzt einen Ping auf ff02::1 vom FTD Joiner aus:
## 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! Bei der Überprüfung der IPv6-Adressen der anderen Geräte sehen wir, dass die erste (die auf 4b1d endet) die LLA des FTD-Kommissars und die zweite (die auf 943b endet) die LLA des RCP-Teilnehmers ist.
Das bedeutet, dass der FTD-Joiner sowohl mit dem FTD-Kommissionär als auch mit dem RCP-Joiner direkt verbunden ist, was unsere Topologie bestätigt.
Mesh-lokal
Der Mesh-lokale Bereich umfasst alle Thread-Schnittstellen, die innerhalb desselben Thread-Netzwerks erreichbar sind. Sehen wir uns die Antworten auf einen Ping an die Multicast-Adresse ff03::1 an.
Ping ff03::1 vom FTD Commissioner aus:
## 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
Diesmal erhielt der FTD-Koordinator zwei Antworten, eine vom Routing Locator (RLOC, endet auf b800) des FTD-Teilnehmers und eine von der Mesh-Local EID (ML-EID, endet auf d55f) des RCP-Teilnehmers. Das liegt daran, dass der mesh-lokale Bereich das gesamte Thread-Netzwerk umfasst. Unabhängig davon, wo sich ein Gerät im Netzwerk befindet, wird es der ff03::1-Adresse zugewiesen.
Pingen Sie ff03::1 vom FTD Joiner aus, 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-Kommissioner (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-Kommissioner zu erreichen, verglichen mit einem Hop für den FTD-Joiner.
Möglicherweise haben Sie auch bemerkt, dass der mesh-lokale Multicast-Ping nur mit dem RLOC für die beiden FTDs geantwortet hat, nicht aber mit dem RCP-Joiner. Das liegt daran, dass die FTDs Router im Netzwerk sind, während das RCP ein Endgerät ist.
Prüfen Sie den Status des RCP Joiners:
## 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 weiterzuleiten (z. B. an das Internet, wenn das Thread-Netzwerk einen Border-Router hat).
UDP-Sockets werden über die OpenThread-Befehlszeile bereitgestellt. Verwenden wir ihn, um Nachrichten zwischen den beiden FTDs zu übergeben.
Rufen Sie die Mesh-lokale EID-Adresse für den FTD-Joiner ab. Wir verwenden diese Adresse, da 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
Wechseln Sie zum FTD Commissioner, starten Sie UDP und stellen Sie über die ML-EID eine Verbindung zum Socket her, den Sie auf dem FTD Joiner eingerichtet haben:
## FTD Commissioner ## ---------------------- > udp open Done > udp connect fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd 1212 Done
Die UDP-Verbindung zwischen den beiden Knoten sollte aktiv sein. So senden Sie eine Nachricht vom FTD-Kommissar:
## FTD Commissioner ## ---------------------- > udp send hellothere Done
Die UDP-Nachricht wurde vom FTD Joiner empfangen.
## FTD Joiner ## ---------------- > 10 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00 49153 hellothere
14. Glückwunsch!
Sie haben ein physisches Thread-Netzwerk erstellt.
Sie wissen jetzt:
- den Unterschied zwischen Thread-Gerätetypen, -Rollen und -Bereichen
- wie Thread-Geräte ihren Status im Netzwerk verwalten
- wie einfache Nachrichten mit UDP zwischen Knoten übergeben werden
Nächste Schritte
Versuchen Sie, anhand dieses Codelabs die folgenden Übungen auszuführen:
- Flashen Sie das FTD-Joiner-Board mit der
ot-cli-mtd-Binärdatei als MTD neu und achten Sie darauf, dass es sich nie selbst zu einem 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.
- NCP mit pyspinel steuern
- Konvertieren Sie den NCP mit dem OpenThread Border Router in einen Border Router und verbinden Sie Ihr Thread-Netzwerk mit dem Internet.
Weitere Informationen
Unter openthread.io und GitHub finden Sie eine Vielzahl von 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 Primer: Deckt alle Thread-Konzepte ab, die in diesem Codelab behandelt werden
Referenz: