1. Wprowadzenie
OpenThread, udostępniony przez Google, to implementacja protokołu sieciowego Thread® w wersji open source. Google Nest udostępniło OpenThread, aby udostępnić deweloperom technologię używaną w produktach Nest. Ma to przyspieszyć rozwój produktów do domu połączonego.
Specyfikacja Thread definiuje niezawodny, bezpieczny i energooszczędny protokół komunikacji bezprzewodowej między urządzeniami na potrzeby zastosowań domowych. OpenThread obsługuje wszystkie warstwy sieciowe Thread, w tym IPv6, 6LoWPAN, IEEE 802.15.4 z zabezpieczeniami MAC, tworzenie połączeń w sieci Mesh oraz routing w sieci Mesh.
W tym Codelab zaprogramujesz OpenThread na prawdziwym sprzęcie, utworzysz sieć Thread i zarządzisz nią, a także przekażesz wiadomości między węzłami.
Czego się nauczysz
- Tworzenie i programowanie binarnych plików OpenThread na płytki deweloperskie
- Tworzenie RCP z komputerem z systemem Linux i płytą deweloperską
- Komunikowanie się z usługą RCP za pomocą demona OpenThread i
ot-ctl - Ręczne zarządzanie węzłami Thread za pomocą GNU Screen i interfejsu wiersza poleceń OpenThread
- Bezpieczne uruchamianie urządzeń w sieci Thread
- Jak działa multicast IPv6
- Przekazywanie wiadomości między węzłami wątku za pomocą protokołu UDP
Czego potrzebujesz
Sprzęt:
- 3 płyty rozwojowe Nordic Semiconductor nRF52840
- 3 kable USB-micro USB do łączenia płytek
- komputer z Linuksem i co najmniej 3 portami USB;
Oprogramowanie:
- GNU Toolchain
- Narzędzia wiersza poleceń Nordic nRF5x
- Oprogramowanie Segger J-Link
- OpenThread
- Git
2. Pierwsze kroki
Symulacja OpenThread
Zanim zaczniesz, możesz zapoznać się z symulacją OpenThread w Codelab, aby poznać podstawowe pojęcia związane z wątkami i interfejsem wiersza poleceń OpenThread.
Terminale z portem szeregowym
Musisz wiedzieć, jak połączyć się z portem szeregowym za pomocą terminala. To Codelab używa GNU Screen i zawiera omówienie jego użytkowania, ale można użyć dowolnego innego oprogramowania terminala.
Urządzenie z systemem Linux
To Codelab zostało zaprojektowane z założenia, aby używać maszyny z systemem Linux na procesorze i386 lub x86 jako hosta dla urządzenia Thread z procesorem współdzielonym (RCP) i do flashowania wszystkich płytek rozwojowych Thread. Wszystkie czynności zostały przetestowane w Ubuntu 14.04.5 LTS (Trusty Tahr).
płyty Nordic Semiconductor nRF52840,
W tym ćwiczeniu Codelab używamy 3 płyt nRF52840 PDK.
Instalowanie SEGGER J-Link
Do programowania płytek nRF52840, które mają wbudowane moduły JTAG, używamy urządzenia SEGGER J-Link. Zainstaluj go na komputerze z Linuksem.
Pobierz odpowiedni pakiet dla swojego komputera i zainstaluj go w odpowiednim miejscu. W Linuksie jest to /opt/SEGGER/JLink.
Instalowanie narzędzi wiersza poleceń nRF5x
Narzędzia wiersza poleceń nRF5x umożliwiają flashowanie plików binarnych OpenThread na płytki nRF52840. Zainstaluj odpowiednią wersję nRF5x-Command-Line-Tools-<OS> na komputerze z systemem Linux.
Umieść wyodrębniony pakiet w folderze głównym ~/
Instalowanie ARM GNU Toolchain
Do kompilacji służy ARM GNU Toolchain.
Zalecamy umieszczenie wyodrębnionego archiwum w folderze /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/ na komputerze z systemem Linux. Postępuj zgodnie z instrukcjami w pliku readme.txt archiwum.
Ekran instalacji (opcjonalnie)
Screen to proste narzędzie do uzyskiwania dostępu do urządzeń połączonych przez port szeregowy. To Codelab korzysta z ekranu, ale możesz użyć dowolnej aplikacji do terminala portu szeregowego.
$ sudo apt-get install screen
3. Klonowanie repozytoriów
OpenThread
Sklonuj i zainstaluj OpenThread. Polecenia script/bootstrap sprawdzają, czy toolchain jest zainstalowany, a środowisko jest prawidłowo skonfigurowane:
$ mkdir -p ~/src $ cd ~/src $ git clone --recursive https://github.com/openthread/openthread.git $ cd openthread $ ./script/bootstrap
Utwórz demona OpenThread:
$ script/cmake-build posix -DOT_DAEMON=ON
Teraz możesz skompilować i przeflashować OpenThread na płytkach nRF52840.
4. Konfigurowanie łącznika RCP
Tworzenie i flash
Utwórz przykład OpenThread nRF52840 z Joinerem i natywną funkcją USB. Urządzenie korzysta z roli dołączającego, aby bezpiecznie uwierzytelnić się i zostać włączone do sieci Thread. Natywne USB umożliwia korzystanie z interfejsu USB CDC ACM jako transportu szeregowego między nRF52840 a hostem.
Najpierw zawsze oczyszcz repozytorium z poprzednich wersji, wykonując polecenie rm -rf build.
$ cd ~/src $ git clone --recursive https://github.com/openthread/ot-nrf528xx.git $ cd ot-nrf528xx $ script/build nrf52840 USB_trans
Przejdź do katalogu z plikiem binarnym OpenThread RCP i przekształć go w format szesnastkowy:
$ cd ~/src/ot-nrf528xx/build/bin $ arm-none-eabi-objcopy -O ihex ot-rcp ot-rcp.hex
Podłącz kabel USB do portu debugowania micro-USB obok pinu zasilania zewnętrznego na płycie nRF52840, a potem podłącz go do komputera z systemem Linux. Przełącznik Źródło zasilania nRF na płycie nRF52840 ustaw na VDD. Po prawidłowym podłączeniu dioda LED5 będzie się świecić.
Jeśli jest to pierwsza płytka podłączona do maszyny z systemem Linux, pojawia się jako port szeregowy /dev/ttyACM0 (wszystkie płytki nRF52840 używają identyfikatora portu szeregowego ttyACM).
$ ls /dev/ttyACM* /dev/ttyACM0
Zapisz numer seryjny płytki nRF52840 używanej do sterowania RCP:
Przejdź do lokalizacji narzędzi wiersza poleceń nRFx i za pomocą numeru seryjnego płytki nRF52840 zapisz plik OpenThread RCP w formacie heksadecymalnym na płytce nRF52840. Pamiętaj, że jeśli pominiesz flagę --verify, zobaczysz komunikat ostrzegawczy informujący, że proces flashowania może się nie udać bez wyświetlenia błędu.
$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
~/src/ot-nrf528xx/build/bin/ot-rcp.hex --reset
Po pomyślnym wykonaniu operacji generowane są następujące dane wyjściowe:
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.
Oznacz tablicę etykietą „RCP”, aby później nie pomylić ról.
Łączenie przez natywne USB
Kompilacja OpenThread RCP umożliwia korzystanie z natywnego interfejsu USB CDC ACM jako transportu szeregowego, dlatego do komunikacji z hostem RCP (komputera z systemem Linux) musisz używać portu nRF USB na płycie nRF52840.
Odłącz kabel USB od portu debugowania na przeflashowanej płycie nRF52840, a następnie podłącz go do portu nRF USB obok przycisku RESET. Przesuń przełącznik Źródło zasilania nRF w pozycję USB.
Uruchamianie demona OpenThread
W ramach rozwiązania RCP do komunikacji z urządzeniem Thread i zarządzania nim używaj demona OpenThread. Uruchom ot-daemon z flagą -v, aby wyświetlić szczegółowy dziennik i sprawdzić, czy narzędzie działa:
$ cd ~/src/openthread
$ sudo ./build/posix/src/posix/ot-daemon -v \
'spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=460800'
Jeśli polecenie ot-daemon w trybie szczegółowym działa prawidłowo, wyświetli się komunikat podobny do tego:
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
Pozostaw to okno terminala otwarte, aby można było wyświetlić logi z ot-daemon.
Użyj adresu ot-ctl do komunikacji z węzłem RCP. ot-ctl używa tego samego interfejsu wiersza poleceń co aplikacja OpenThread CLI. Dlatego możesz sterować węzłami ot-daemon w taki sam sposób jak innymi symulowanymi urządzeniami Thread.
W drugim oknie terminala uruchom ot-ctl:
$ sudo ./build/posix/src/posix/ot-ctl >
Sprawdź state węzła 2 (węzła RCP), który został utworzony z poziomu węzła ot-daemon:
> state disabled Done
5. Konfigurowanie FTD
Pozostałe 2 węzły Thread używane w tym Codelab to urządzenia Full Thread (FTD) o standardowej architekturze System-on-Chip (SoC). W ustawieniach produkcyjnych można użyć sterownika interfejsu sieciowego wpantund, aby kontrolować instancje OpenThread NCP, ale w tym ćwiczeniu użyjemy ot-ctl, interfejsu wiersza poleceń OpenThread.
Jedno urządzenie pełni rolę komisarza, aby bezpiecznie uwierzytelniać urządzenia i wprowadzać je do sieci. Drugie urządzenie działa jako urządzenie dołączające, które może uwierzytelnić się w sieci Thread.
Tworzenie i flash
Utwórz przykład FTD OpenThread na platformę nRF52840 z włączonymi rolami komisarza i członka:
$ cd ~/src/ot-nrf528xx $ rm -rf build $ script/build nrf52840 USB_trans -DOT_JOINER=ON -DOT_COMMISSIONER=ON
Przejdź do katalogu z binarnym interfejsem wiersza poleceń OpenThread Full Thread Device (FTD) i przekształć go do formatu szesnastkowego:
$ cd ~/src/ot-nrf528xx/build/bin $ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex
Podłącz kabel USB do portu micro-USB obok pinu zasilania zewnętrznego na płycie nRF52840, a potem podłącz go do komputera z systemem Linux. Jeśli RCP jest nadal podłączony do komputera z systemem Linux, nowa płytka powinna być widoczna jako port szeregowy /dev/ttyACM1 (wszystkie płytki nRF52840 używają identyfikatora portu szeregowego ttyACM).
$ ls /dev/ttyACM* /dev/ttyACM0 /dev/ttyACM1
Podobnie jak poprzednio, zapisz numer seryjny płytki nRF52840 używanej do FTD:
Przejdź do lokalizacji narzędzi wiersza poleceń nRFx i za pomocą numeru seryjnego płytki zapisz plik FTD OpenThread CLI na płytce nRF52840:
$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
~/src/ot-nrf528xx/build/bin/ot-cli-ftd.hex --reset
Nazwij tablicę „Commissioner”.
Łączenie przez natywne USB
Kompilacja OpenThread FTD umożliwia korzystanie z natywnego interfejsu USB CDC ACM jako transportu szeregowego, dlatego do komunikacji z hostem RCP (komputera z systemem Linux) musisz używać portu nRF USB na płycie nRF52840.
Odłącz kabel USB od portu debugowania na przeflashowanej płycie nRF52840, a potem podłącz go do portu nRF USB obok przycisku RESET. Przesuń przełącznik Źródło zasilania nRF w pozycję USB.
Weryfikowanie kompilacji
Aby sprawdzić, czy kompilacja przebiegła pomyślnie, otwórz interfejs wiersza poleceń OpenThread za pomocą GNU Screen w oknie terminala.
$ screen /dev/ttyACM1
W nowym oknie naciśnij kilka razy klawisz Return, aby wyświetlić prompt > interfejsu wiersza poleceń OpenThread. Uruchom interfejs IPv6 i sprawdź adresy:
> ifconfig up Done > ipaddr fe80:0:0:0:1cd6:87a9:cb9d:4b1d Done
Użyj Ctrl+A →
d aby odłączyć się od konsoli FTD Commissioner CLI i wrócić do terminala Linuksa, aby móc zaprogramować kolejną płytkę. Aby w dowolnym momencie ponownie otworzyć interfejs wiersza poleceń, użyj polecenia screen -r z poziomu wiersza poleceń. Aby wyświetlić listę dostępnych ekranów, użyj screen -ls:
$ screen -ls
There is a screen on:
74182.ttys000.mylinuxmachine (Detached)
1 Socket in /tmp/uscreens/S-username.
Konfigurowanie złącza FTD
Powtórz powyższą procedurę, aby zaprogramować trzecią płytkę nRF52840, używając istniejącej wersji ot-cli-ftd.hex. Po zakończeniu ponownie podłącz płytkę do komputera za pomocą portu USB nRF i ustaw przełącznik nRF power source (Źródło zasilania nRF) na VDD.
Jeśli po podłączeniu tej trzeciej płyty 2 inne węzły są podłączone do maszyny z Linuxem, powinna ona być widoczna jako port szeregowy /dev/ttyACM2:
$ ls /dev/ttyACM* /dev/ttyACM0 /dev/ttyACM1 /dev/ttyACM2
Nazwij tablicę „Joiner”.
Podczas weryfikacji za pomocą Screen zamiast tworzyć nową instancję Screen z wiersza poleceń, ponownie połącz się z istniejącą instancją i utwórz w niej nowe okno (którego używasz do weryfikacji za pomocą narzędzia FTD Commissioner):
$ screen -r
Utwórz nowe okno w Screen za pomocą Ctrl + A → c.
Pojawi się nowe okno wiersza polecenia. Otwórz interfejs wiersza poleceń OpenThread dla FTD Joiner:
$ screen /dev/ttyACM2
W nowym oknie naciśnij kilka razy klawisz Return, aby wyświetlić prompt > interfejsu wiersza OpenThread. Uruchom interfejs IPv6 i sprawdź adresy:
> ifconfig up Done > ipaddr fe80:0:0:0:6c1e:87a2:df05:c240 Done
Ponieważ narzędzie FTD Joiner CLI znajduje się w tej samej instancji Screen co narzędzie FTD Commissioner, możesz przełączać się między nimi za pomocą Ctrl+a → n.
Użyj Ctrl+A →
d w dowolnym momencie, aby zamknąć ekran.
6. Konfiguracja okna terminala
W przyszłości będziesz często przełączać się między urządzeniami w sieci Thread, więc upewnij się, że wszystkie są aktywne i łatwo dostępne. Do tej pory używaliśmy Screen do uzyskiwania dostępu do 2 FTD. To narzędzie umożliwia też podzielenie ekranu w tym samym oknie terminala. Dzięki temu możesz sprawdzić, jak jeden węzeł reaguje na polecenia wydawane przez inny węzeł.
W najlepszym przypadku powinno być widocznych 4 okna:
ot-daemonusługa / logi- RCP Joiner za pomocą
ot-ctl - FTD Commissioner za pomocą interfejsu wiersza poleceń OpenThread
- FTD Joiner za pomocą interfejsu wiersza poleceń OpenThread
Jeśli chcesz użyć własnej konfiguracji terminala lub portu szeregowego, przejdź do następnego kroku. Skonfiguruj okna terminala na wszystkich urządzeniach w sposób, który najbardziej Ci odpowiada.
Korzystanie z ekranu
Aby ułatwić korzystanie z tej funkcji, uruchom tylko jedną sesję ekranu. Powinieneś już mieć jeden z czasów konfigurowania obu usług FTD.
Wszystkie polecenia w oknie zaczynają się od Ctrl+A.
Podstawowe polecenia ekranu:
Ponowne dołączenie do sesji udostępniania ekranu (z poziomu wiersza poleceń) |
|
Zakończ sesję ekranu | Ctrl+a → |
Tworzenie nowego okna w ramach sesji udostępniania ekranu | Ctrl+a → |
Przełączanie się między oknami w ramach tej samej sesji ekranu | Ctrl+a → |
Zamknij bieżące okno w sesji udostępniania ekranu | Ctrl+a → |
Podzielony ekran
Za pomocą Screen możesz podzielić terminal na kilka okien:
Aby uzyskać dostęp do poleceń w sekcji screen, naciśnij Ctrl + A. Każda komenda powinna zaczynać się od tego klucza dostępu.
Jeśli dokładnie postępujesz zgodnie z instrukcjami w Codelab, na tym samym ekranie powinny być 2 okna (FTD Commissioner i FTD Joiner). Aby podzielić ekran na 2 części, najpierw otwórz istniejące spotkanie na ekranie:
$ screen -r
Musisz korzystać z jednego z urządzeń FTD. W ekranie wykonaj te czynności:
- Ctrl + a →
S, aby podzielić okno poziomo. - Ctrl+a →
Tab, aby przenieść kursor do nowego pustego okna. - Ctrl + A →
n, aby przejść do następnego okna. - Jeśli jest to to samo okno, co w górnej części, naciśnij Ctrl + A →
n, aby wyświetlić inne urządzenie FTD
Są teraz widoczne. Przełącz się między nimi za pomocą Ctrl + A → Tab. Aby uniknąć nieporozumień, zalecamy zmianę nazwy każdego okna za pomocą Ctrl+A → A.
Zaawansowane użycie
Aby podzielić ekran na kwadraty i wyświetlić logi ot-daemon oraz narzędzie RCP Joiner ot-ctl, te usługi muszą być uruchomione w ramach tego samego wystąpienia ekranu. Aby to zrobić, zatrzymaj ot-daemon i zamknij ot-ctl, a następnie uruchom je ponownie w nowych oknach Screen (Ctrl+a → c).
Ta konfiguracja nie jest wymagana i zostaje pozostawiona do wykonania przez użytkownika.
Aby podzielić okno i przełączać się między oknami, użyj tych poleceń:
Tworzenie nowego okna | Ctrl+a → |
Podział okna w pionie | Ctrl+a → |
Podział okna w poziomie | Ctrl+a → |
Przejście do następnego wyświetlanego okna | Ctrl+a → |
przełączanie wyświetlanego okna do przodu lub do tyłu, | Ctrl+a → |
Zmiana nazwy bieżącego okna | Ctrl+a → |
W każdej chwili możesz opuścić Screen, naciskając Ctrl + a → d, a potem ponownie połączyć się z nim, naciskając d na linii poleceń.screen -r
Więcej informacji o Screen znajdziesz w krótkim przewodniku GNU Screen.
7. Tworzenie sieci Thread
Gdy masz już skonfigurowane wszystkie okna i ekrany terminala, utwórz sieć Thread. Na koncie FTD Commissioner utwórz nowy operacyjny zbiór danych i zapisz go jako aktywny. Operacyjny zbiór danych to konfiguracja sieci Thread, którą tworzysz.
## 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
Zapisz klucz sieciowy 1234c0de7ab51234c0de7ab51234c0de, który będzie używany później.
Zapisz ten zbiór danych jako aktywny:
> dataset commit active Done
Uruchom interfejs IPv6:
> ifconfig up Done
Rozpoczęcie operacji protokołu wątku:
> thread start Done
Po chwili sprawdź stan urządzenia. Powinien to być Lider. Uzyskaj też RLOC16 na przyszłość.
## FTD Commissioner ## ---------------------- > state leader Done > rloc16 0c00 Done
Sprawdź adresy IPv6 urządzenia:
## 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)
Sieć „codelab” jest teraz widoczna po zeskanowaniu z innych urządzeń Thread.
Od ot-ctl na RCP Joiner:
## RCP Joiner ## ---------------- > scan | PAN | MAC Address | Ch | dBm | LQI | +------+------------------+----+-----+-----+ | c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |
W interfejsie wiersza poleceń OpenThread na urządzeniu FTD Joiner:
## FTD Joiner ## ---------------- > scan | PAN | MAC Address | Ch | dBm | LQI | +------+------------------+----+-----+-----+ | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |
Jeśli sieć „codelab” nie pojawia się na liście, spróbuj ponownie zeskanować.
8. Dodawanie złącza RCP
W sieci nie jest aktywne uruchamianie wątku, co oznacza, że musimy dodać złącze RCP do utworzonej przez nas właśnie sieci Thread, korzystając z procesu uruchamiania poza pasmem.
W przypadku Komisarza FTD zapisaliśmy klucz sieci, np. 1234c0de7ab51234c0de7ab51234c0de. Jeśli chcesz ponownie sprawdzić klucz sieci, uruchom to polecenie w komisarzu FTD:
## FTD Commissioner ## > dataset networkkey 1234c0de7ab51234c0de7ab51234c0de Done
Następnie na węźle RCP ustaw klucz sieciowy aktywnego zbioru danych na klucz sieciowy komisarza FTD:
## RCP Joiner ## ---------------- > dataset networkkey 1234c0de7ab51234c0de7ab51234c0de Done > dataset commit active Done
Sprawdź, czy zbiór danych jest prawidłowo skonfigurowany.
## RCP Joiner ## ---------------- > dataset Network Key: 1234c0de7ab51234c0de7ab51234c0de
Uruchom wątk, aby osoba dołączająca do RCP dołączyła do sieci „codelab”. Zaczekaj kilka sekund, a potem sprawdź stan, RLOC16 i adresy IPv6:
## 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
Zapisz adres IPv6 Mesh-Local (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f), ponieważ będzie on potrzebny później.
W narzędziu FTD Commissioner sprawdź tabele routera i urządzeń podrzędnych, aby potwierdzić, że oba urządzenia znajdują się w tej samej sieci. Użyj RLOC16, aby zidentyfikować złączający RCP.
## FTD Commissioner ## ---------------------- > router table | ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC | +----+--------+----------+-----------+-------+--------+-----+------------------+ | 3 | 0x0c00 | 3 | 0 | 0 | 0 | 35 | 1ed687a9cb9d4b1d | Done > child table | ID | RLOC16 | Timeout | Age | LQ In | C_VN |R|S|D|VER| Extended MAC | +-----+--------+------------+------------+-------+------+-+-+-+---+------------------+ | 1 | 0x0c01 | 240 | 25 | 3 | 89 |1|1|1| 2| 1ae529b3a638943b | Done
Aby sprawdzić łączność, wyślij ping do adresu lokalnego w sieci mesh (adresu lokalnego w sieci mesh uzyskanego z wyjścia ipaddr urządzenia RCP Joiner):
## 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
Mamy teraz sieć Thread składającą się z 2 węzłów, jak pokazano na tym diagramie topologii:
Diagramy topologii
W dalszej części tego Codelaba, gdy tylko stan sieci się zmieni, wyświetlimy nowy diagram topologii wątku. Role węzła są oznaczane w ten sposób:
Routery są zawsze pięciokątami, a urządzenia końcowe są zawsze okręgami. Liczby przy każdym węźle odpowiadają identyfikatorowi routera lub podrzędnego, który jest widoczny w wyniku polecenia wiersza poleceń, w zależności od bieżącej roli i stanu danego węzła.
9. Zamówienie usługi FTD
Teraz dodaj trzecie urządzenie Thread do sieci „codelab”. Tym razem użyjemy bezpieczniejszego procesu inicjowania w zakresie i zezwolimy na dołączenie tylko dołączającemu urządzeniu FTD.
W przypadku uczestnika w programie FTD: eui64, aby komisarz ds. programu FTD mógł go zidentyfikować:
## FTD Joiner ## ---------------- > eui64 2f57d222545271f1 Done
W usługach FTD Commissioner uruchom komisarza i wskaż eui64 urządzenia, które może dołączyć, wraz z danymi logowania osoby dołączającej, na przykład J01NME. Identyfikator osoby dołączającej to ciąg znaków alfanumerycznych (0–9 i A–Y, z wyjątkiem liter I, O, Q i Z ze względu na czytelność) o długości od 6 do 32 znaków, który jest specyficzny dla urządzenia.
## FTD Commissioner ## ---------------------- > commissioner start Done > commissioner joiner add 2f57d222545271f1 J01NME Done
Przełącz się na Narzędzie złączające FTD. Uruchom rolę osoby dołączającej za pomocą danych logowania osoby dołączającej, które właśnie skonfigurowałeś/skonfigurowałaś w usługach FTD Commissioner:
## FTD Joiner ## ---------------- > ifconfig up Done > joiner start J01NME Done
W ciągu minuty otrzymasz potwierdzenie uwierzytelnienia:
## FTD Joiner ## ---------------- > Join success
Otwórz wątki, aby złącznik FTD dołączył do sieci „codelab”, i natychmiast sprawdź stan i RLOC16:
## FTD Joiner ## ---------------- > thread start Done > state child Done > rloc16 0c02 Done
Sprawdź adresy IPv6 urządzenia. Zwróć uwagę, że nie ma żadnych informacji o przypisaniu. Dzieje się tak, ponieważ to urządzenie nie jest urządzeniem dominującymi ani nie pełni roli specyficznej dla Anycast, która wymaga ALOC.
## 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)
Natychmiast przełącz się na konto FTD Commissioner i sprawdź tabele routera i urządzeń podrzędnych, aby potwierdzić, że w sieci „codelab” znajdują się 3 urządzenia:
## 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
Zgodnie z RLOC16 urządzenie dołączające FTD zostało połączone z siecią jako urządzenie końcowe (podrzędne). Oto zaktualizowana topologia:
10. Wątek w działaniu
Urządzenia Thread w tym Codelab to specyficzny rodzaj pełnego urządzenia Thread (FTD) zwany urządzeniem końcowym z możliwością podłączenia do routera (REED). Oznacza to, że mogą działać jako router lub urządzenie końcowe i mogą przekształcić się z urządzenia końcowego w router.
Sieć Thread może obsługiwać do 32 routerów, ale stara się utrzymywać ich liczbę na poziomie od 16 do 23. Jeśli REED łączy się jako urządzenie końcowe (podrzędne), a liczba routerów jest mniejsza niż 16, po losowym upływie czasu w ciągu 2 minut automatycznie awansuje do roli routera.
Jeśli po dodaniu urządzenia FTD Joiner w Twojej sieci Thread były 2 urządzenia podrzędne, odczekaj co najmniej 2 minuty, a potem ponownie sprawdź tabele routera i urządzeń podrzędnych na urządzeniu FTD Commissioner:
## 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
Urządzenie FTD Joiner (rozszerzony adres MAC e6cdd2d93249a243) zostało awansowane do roli routera. Pamiętaj, że RLOC16 jest inny (b800 zamiast 0c02). Wynika to z tego, że RLOC16 jest oparty na identyfikatorze routera i podrzędnego urządzenia. Gdy przejście z urządzenia końcowego na router, zmieniają się wartości identyfikatora routera i podrzędnego, a także RLOC16.
Sprawdź nowy stan i RLOC16 na urządzeniu FTD Joiner:
## FTD Joiner ## ---------------- > state router Done > rloc16 b800 Done
Przejście na niższą wersję usługi FTD Joiner
Możesz przetestować to zachowanie, ręcznie obniżając poziom FTD Joiner z Routera z powrotem do urządzenia końcowego. Zmień stan na „podrzędny” i sprawdź RLOC16:
## FTD Joiner ## ---------------- > state child Done > rloc16 0c03 Done
Wróć do Komisarza FTD. W tabeli podrzędnej (ID = 3) powinien teraz pojawić się uczestnik FTD. Może być nawet w obu podczas przenoszenia:
## 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
Po pewnym czasie przełączy się z powrotem na router z wartością RLOC b800.
Usuwanie lidera
Lider jest wybierany przez siebie spośród wszystkich routerów w wątku. Oznacza to, że jeśli bieżący lider zostanie usunięty z sieci Thread, jeden z innych routerów stanie się nowym liderem.
W urządzeniu FTD Commissioner wyłącz Thread, aby usunąć je z sieci Thread:
## FTD Commissioner ## ---------------------- > thread stop Done > ifconfig down Done
W ciągu 2 minut osoba dołączająca do wątku za pomocą funkcji FTD staje się nowym liderem wątku. Sprawdź stan i adresy IPv6 urządzenia FTD Joiner, aby zweryfikować:
## 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
Sprawdź tabelę podrzędną. Zwróć uwagę, że jest nowy RLOC16. To jest urządzenie RCP Joiner, jak wskazuje jego identyfikator i rozszerzony adres MAC. Aby utrzymać sieć Thread w jednym miejscu, routery nadrzędne zostały przełączone z komisarza FTD na urządzenie FTD Joiner. W rezultacie dla złącza RCP zostanie utworzony nowy identyfikator RLOC16 (ponieważ identyfikator routera zmienił się z 3 na 46).
## FTD Joiner ## ---------------- > child table | ID | RLOC16 | Timeout | Age | LQ In | C_VN |R|S|D|N| Extended MAC | +-----+--------+------------+------------+-------+------+-+-+-+-+------------------+ | 1 | 0xb801 | 240 | 27 | 3 | 145 |1|1|1|1| 1ae529b3a638943b | Done
Możesz musieć zaczekać kilka minut, aż element RCP Joiner zostanie dołączony do elementu FTD Joiner jako element podrzędny. Sprawdź stan i RLOC16, aby potwierdzić, że:
## RCP Joiner ## -------------- > state child > rloc16 b801
Ponownie dołącz do Komisji ds. FTD
Sieć Thread z 2 węzłami nie jest zbyt przydatna. Przywróćmy połączenie z komisarzem FTD.
Na koncie FTD Commissioner uruchom ponownie wątek:
## FTD Commissioner ## ---------------------- > ifconfig up Done > thread start Done
W ciągu 2 minut automatycznie ponownie łączy się z siecią „codelab” jako urządzenie końcowe, a potem awansuje do roli routera.
## FTD Commissioner ## ---------------------- > state router Done
Sprawdź router i tabele podrzędne w FTD Joiner, aby potwierdzić:
## 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
Nasze połączenie Thread składa się z 3 węzłów.
11. Rozwiązywanie problemów
Zarządzanie siecią Thread z wieloma urządzeniami na różnych terminalach lub w oknach ekranu może być skomplikowane. Jeśli napotkasz problemy, skorzystaj z tych wskazówek, aby „zresetować” stan sieci lub obszaru roboczego.
Ekran
Jeśli kiedykolwiek tracisz orientację w konfiguracji (za dużo okien Screen lub Screen w Screen), zabijaj okna Screen za pomocą Ctrl+a → k, aż nie będzie już żadnych okien. W wyniku screen -ls w wierszu poleceń powinno być No Sockets found. Następnie utwórz okna ekranu dla każdego urządzenia. Stany urządzenia są zachowywane nawet wtedy, gdy usługa Ekran zostanie zatrzymana.
Węzły wątku
Jeśli topologia sieci Thread nie jest zgodna z opisem w tym Codelab lub węzły zostaną z jakiegoś powodu odłączone (być może dlatego, że maszyna z systemem Linux, która je obsługuje, przeszła w stan uśpienia), najlepiej wyłączyć Thread, wyczyścić poświadczenia sieci i zaczynać od kroku Tworzenie sieci Thread.
Aby zresetować FTD:
## FTD Commissioner or FTD Joiner ## ------------------------------------ > thread stop Done > ifconfig down Done > factoryreset Done
Urządzenie RCP można zresetować w ten sam sposób za pomocą ot-ctl:
## RCP Joiner ## ---------------- > thread stop Done > ifconfig down Done > factoryreset Done
12. Korzystanie z multicastu
Multicast służy do przesyłania informacji do grupy urządzeń jednocześnie. W sieci Thread konkretne adresy są zarezerwowane do użytku multicastowego w różnych grupach urządzeń, w zależności od zakresu.
Adres IPv6 | Zakres | Dostarczono do |
| Link-Local | Wszystkie FTD i MED |
| Link-Local | Wszystkie urządzenia FTD i routery graniczne |
| Mesh-Local | Wszystkie FTD i MED |
| Mesh-Local | Wszystkie urządzenia FTD i routery graniczne |
W tym Codelab nie używamy routera granicznego, więc skupmy się na dwóch adresach wielodostępowych FTD i MED.
Link-Local
Zakres lokalny obejmuje wszystkie interfejsy Thread dostępne za pomocą pojedynczego przesyłania radiowego lub pojedynczego „przeskoczenia”. Topologia sieci określa, które urządzenia odpowiadają na ping do adresu ff02::1.
Ping ff02::1 z komisji FTD:
## FTD Commissioner ## ---------------------- > ping ff02::1 > 8 bytes from fe80:0:0:0:e4cd:d2d9:3249:a243: icmp_seq=2 hlim=64 time=9ms
W sieci są 2 inne urządzenia (FTD Joiner i RCP Joiner), ale Komisarz FTD otrzymał tylko jedną odpowiedź z adresu lokalnego łącza (LLA) urządzenia FTD Joiner. Oznacza to, że urządzenie dołączające do sieci FTD jest jedynym urządzeniem, do którego inicjator może dotrzeć w jednym skoku.
Teraz prześlij ping ff02::1 z elementu 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
2 odpowiedzi Sprawdzając adresy IPv6 innych urządzeń, widzimy, że pierwszy z nich (kończący się na 4b1d) to LLA komisarza FTD, a drugi (kończący się na 943b) to LLA użytkownika RCP.
Oznacza to, że złącze FTD jest bezpośrednio połączone z zarówno zleceniodawcą FTD, jak i złączem RCP, co potwierdza naszą topologię.
Mesh-Local
Zakres lokalny obejmuje wszystkie interfejsy Thread dostępne w ramach tej samej sieci Thread. Sprawdźmy odpowiedzi na ping wysłany do adresu multicast ff03::1.
Ping ff03::1 z komisji FTD:
## FTD Commissioner ## ---------------------- > ping ff03::1 > 8 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:b800: icmp_seq=3 hlim=64 time=9ms 8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=3 hlim=64 time=68ms
Tym razem komisarz FTD otrzymał 2 odpowiedzi: jedną z lokalizatora routingu (RLOC) urządzenia FTD (kończącego się na b800) i jedną z identyfikatora EID lokalnego w sieci (ML-EID) urządzenia RCP (kończącego się na d55f). Wynika to z tego, że zakres lokalny w sieci obejmuje całą sieć Thread. Niezależnie od tego, gdzie w sieci znajduje się urządzenie, będzie ono subskrybować adres ff03::1.
Aby potwierdzić to zachowanie, wysyłaj ping do ff03::1 z złączenia FTD:
## 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
Zwróć uwagę na czas odpowiedzi łącznika RCP w obu wyjściach pinga. Dojście do komisarza RCP (68 ms) zajęło znacznie więcej czasu niż dołączenie do FTD (23 ms). Dzieje się tak, ponieważ musi ono wykonać 2 przeskoki, aby dotrzeć do komisarza FTD, w porównaniu z 1 przeskokiem w przypadku dołączenia FTD.
Możesz też zauważyć, że ping w sieci mesh odpowiadał z lokalizacją RLOC tylko dla 2 urządzeń FTD, a nie dla urządzenia RCP Joiner. Dzieje się tak, ponieważ FTD to routery w sieci, a RCP to urządzenie końcowe.
Sprawdź stan usługa RCP Joiner, aby potwierdzić:
## RCP Joiner ## ---------------- > state child
13. Wysyłanie wiadomości za pomocą protokołu UDP
Jedną z usług aplikacji, które udostępnia OpenThread, jest protokół User Datagram Protocol (UDP), czyli protokół warstwy transportowej. Aplikacja oparta na OpenThread może używać interfejsu UDP API do przekazywania wiadomości między węzłami w sieci Thread lub do innych urządzeń w sieci zewnętrznej (np. do internetu, jeśli sieć Thread zawiera router graniczny).
Gniazdka UDP są dostępne przez interfejs wiersza poleceń OpenThread. Użyj go do przekazywania wiadomości między 2 punktami dostępu FTD.
Uzyskaj adres EID Mesh-Local dla elementu FTD Joiner. Używamy tego adresu, ponieważ jest on dostępny z dowolnego miejsca w ramach sieci Thread.
## FTD Joiner ## ---------------- > ipaddr fdc0:de7a:b5c0:0:0:ff:fe00:fc00 # Leader Anycast Locator (ALOC) fdc0:de7a:b5c0:0:0:ff:fe00:b800 # Routing Locator (RLOC) fe80:0:0:0:e4cd:d2d9:3249:a243 # Link-Local Address (LLA) fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd # Mesh-Local EID (ML-EID) Done
Uruchom UDP i połącz go z gniazdem dla dowolnego adresu IPv6:
## FTD Joiner ## ---------------- > udp open Done > udp bind :: 1212
Przełącz się na FTD Commissioner, uruchom UDP i połącz się z gniazdem skonfigurowanym na urządzeniu FTD Joiner, używając identyfikatora ML-EID:
## FTD Commissioner ## ---------------------- > udp open Done > udp connect fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd 1212 Done
Połączenie UDP powinno być aktywne między tymi dwoma węzłami. Wysyłanie wiadomości od komisarza FTD:
## FTD Commissioner ## ---------------------- > udp send hellothere Done
Na urządzeniu FTD Joiner odebrano wiadomość UDP.
## FTD Joiner ## ---------------- > 10 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00 49153 hellothere
14. Gratulacje!
Udało Ci się utworzyć fizyczną sieć Thread.
Wiesz już:
- różnice między typami, rolami i zakresami urządzeń Thread
- jak urządzenia Thread zarządzają swoimi stanami w sieci;
- jak przekazywać proste wiadomości między węzłami za pomocą protokołu UDP;
Dalsze kroki
Na podstawie tego ćwiczenia Codelab spróbuj wykonać te ćwiczenia:
- Ponownie przeflashuj płytkę FTD Joiner jako MTD, używając binarnego pliku
ot-cli-mtd. Zwróć uwagę, że nigdy nie awansuje do roli Routera ani nie próbuje zostać Liderem. - Dodaj do sieci więcej urządzeń (spróbuj użyć innej platformy) i narysuj topologię za pomocą tabel routera i podrzędnych oraz pingowania adresów multicast.
- Używanie pyspinel do sterowania NCP
- Przekształć NCP w router graniczny za pomocą OpenThread Border Router i połącz sieć Thread z internetem.
Więcej informacji
Odwiedź stronę openthread.io i GitHub, aby znaleźć różne zasoby OpenThread, w tym:
- Obsługiwane platformy – poznaj wszystkie platformy obsługujące OpenThread.
- Kompilowanie OpenThread – dodatkowe informacje o kompilowaniu i konfigurowaniu OpenThread
- Wprowadzenie do wątków – obejmuje wszystkie pojęcia dotyczące wątków omawiane w tym ćwiczeniu z programowania.
Materiały referencyjne: