1. Introducción
OpenThread, lanzado por Google, es una implementación de código abierto del protocolo de red Thread®. Google Nest lanzó OpenThread a fin de que la tecnología que se usa en los productos Nest esté disponible para los desarrolladores con el fin de acelerar el desarrollo de productos para el hogar conectado.
La especificación de Thread define un protocolo de comunicación de dispositivos inalámbricos, seguro y de bajo consumo basado en IPv6 para aplicaciones domésticas. OpenThread implementa todas las capas de herramientas de redes de Thread, como IPv6, 6LoWPAN, IEEE 802.15.4 con seguridad MAC, establecimiento de vínculos de malla y enrutamiento de malla.
En este Codelab, vas a programar OpenThread en hardware real, crear y administrar una red Thread, y pasar mensajes entre nodos.
Qué aprenderás
- Cómo compilar e instalar objetos binarios de la CLI de OpenThread en placas de desarrollo
- Cómo compilar un RCP compuesto por una máquina Linux y una placa de desarrollo
- Cómo comunicarse con un RCP mediante OpenThread Daemon y
ot-ctl - Cómo administrar de forma manual los nodos de Thread con la pantalla GNU y la CLI de OpenThread
- Asignación de dispositivos segura a una red Thread
- Cómo funciona la multidifusión IPv6
- Cómo pasar mensajes entre nodos de subprocesos con UDP
Requisitos
Hardware:
- 3 placas de desarrollo Nordic Semiconductor nRF52840
- 3 cables USB a Micro USB para conectar las placas
- Una máquina Linux con al menos 3 puertos USB
Software:
- Conjunto de herramientas de GNU
- Herramientas de línea de comandos nRF5x nórdicas
- Software Segger J-Link
- OpenThread
- Git
2. Primeros pasos
Simulación de OpenThread
Antes de comenzar, te recomendamos que ejecutes el Codelab de simulación de OpenThread para familiarizarte con los conceptos básicos de Thread y la CLI de OpenThread.
Terminales de puerto en serie
Debes estar familiarizado con el modo de conexión a un puerto en serie a través de una terminal. En este Codelab, se usa la pantalla GNU y se proporciona una descripción general del uso, pero se puede usar cualquier otro software de la terminal.
Máquina Linux
Este Codelab fue diseñado para usar una máquina Linux basada en i386 o x86 como host para un dispositivo Thread de radioprocesador (RCP) y escribir en la memoria flash todas las placas de desarrollo de Thread. Todos los pasos se probaron en Ubuntu 14.04.5 LTS (Trusty Tahr).
Placas nRF52840 Semiconductors de Nordic
Este Codelab usa tres placas de PDK nRF52840.
Instalar SEGGER J-Link
Utilizamos SEGGER J-Link para programar las placas nRF52840, que tienen módulos JTAG integrados. Instálala en tu máquina Linux.
Descarga el paquete adecuado para tu máquina y, luego, instálalo en la ubicación adecuada. En Linux, es /opt/SEGGER/JLink.
Instala herramientas de línea de comandos nRF5x
Las herramientas de línea de comandos nRF5x te permiten escribir en la memoria flash los objetos binarios de OpenThread en las placas nRF52840. Instala la compilación nRF5x-Command-Line-Tools-<OS> adecuada en tu máquina Linux.
Coloca el paquete extraído en la carpeta raíz ~/
Instalar la cadena de herramientas de GNU GNU
Se usa la cadena de herramientas de GNU GNU para la compilación.
Te recomendamos que coloques el archivo extraído en /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/, en tu máquina Linux. Sigue las instrucciones del archivo readme.txt para obtener instrucciones de instalación.
Pantalla de instalación (opcional)
La pantalla es una herramienta simple para acceder a dispositivos conectados mediante un puerto en serie. Este Codelab usa Screen, pero puedes usar cualquier aplicación de terminal del puerto en serie que desees.
$ sudo apt-get install screen
3. Clone repositorios
OpenThread
Clona e instala OpenThread. Los comandos script/bootstrap garantizan que la cadena de herramientas esté instalada y que el entorno esté configurado de forma correcta:
$ mkdir -p ~/src $ cd ~/src $ git clone --recursive https://github.com/openthread/openthread.git $ cd openthread $ ./script/bootstrap
Compila un daemon de OpenThread:
$ script/cmake-build posix -DOT_DAEMON=ON
Ahora está listo para crear y escribir OpenThread en las placas nRF52840.
4. Configure el RCP Joiner
Compilación y escritura en la memoria flash
Compila el ejemplo nRF52840 de OpenThread con Joiner y la funcionalidad USB nativa. Un dispositivo usa la función de Joiner para autenticarse de forma segura y encararla en una red Thread. El USB nativo permite el uso de ACM USB CDC como transporte en serie entre el nRF52840 y el host.
Para limpiar siempre el repositorio de compilaciones anteriores, ejecuta rm -rf build.
$ cd ~/src $ git clone --recursive https://github.com/openthread/ot-nrf528xx.git $ cd ot-nrf528xx $ script/build nrf52840 USB_trans
Navega al directorio con el objeto binario RCP de OpenThread y conviértelo al formato hexadecimal:
$ cd ~/src/ot-nrf528xx/build/bin $ arm-none-eabi-objcopy -O ihex ot-rcp ot-rcp.hex
Conecta el cable USB al puerto de depuración micro-USB que se encuentra junto al pin de alimentación externo de la placa nRF52840 y, luego, conéctalo a la máquina Linux. Establece el interruptor de fuente de alimentación de nRF en la placa nRF52840 como VDD. Cuando se conecta correctamente, el LED5 está activado.
Si esta es la primera placa conectada a la máquina Linux, aparece como puerto en serie /dev/ttyACM0 (todas las placas nRF52840 usan ttyACM para el identificador de puerto en serie).
$ ls /dev/ttyACM* /dev/ttyACM0
Ten en cuenta el número de serie de la placa nRF52840 que se usa para el RCP:
Navega hasta la ubicación de las herramientas de línea de comandos nRFx y escribe el archivo hexadecimal RCP de OpenThread en la placa nRF52840. Para ello, usa el número de serie de la placa. Ten en cuenta que, si omites la marca --verify, verás un mensaje de advertencia que indica que el proceso de Flash puede fallar sin errores.
$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
~/src/ot-nrf528xx/build/bin/ot-rcp.hex --reset
El siguiente resultado se genera cuando se ejecuta de forma correcta:
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.
Etiqueta la placa "RCP" para que luego no confundas las funciones de la pizarra.
Conectar a USB nativo
Debido a que la compilación de RCP de OpenThread permite el uso de ACM USB de CDC nativo como transporte en serie, debes usar el puerto nRF USB en la placa nRF52840 para comunicarte con el host de RCP (máquina Linux).
Desconecta el extremo micro-USB del cable USB del puerto de depuración de la placa nRF52840 parpadeante y, luego, vuelve a conectarlo al puerto micro-USB nRF USB junto al botón RESTABLECER. Establece el interruptor de Fuente de alimentación nRF en USB.
Iniciar OpenThread Daemon
En el diseño de RCP, usa OpenThread Daemon para comunicarte con el dispositivo Thread y administrarlo. Inicia ot-daemon con la marca detallada -v para que puedas ver el resultado del registro y confirmar que se esté ejecutando:
$ cd ~/src/openthread
$ sudo ./build/posix/src/posix/ot-daemon -v \
'spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=115200'
Cuando se ejecuta de forma correcta, ot-daemon en modo detallado genera un resultado similar al siguiente:
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
Deja esta ventana de terminal abierta para que se puedan ver los registros de ot-daemon.
Usa ot-ctl para comunicarte con el nodo de RCP. ot-ctl usa la misma CLI que la app de CLI de OpenThread. Por lo tanto, puedes controlar los nodos ot-daemon de la misma manera que los otros dispositivos simulados de Thread.
En una segunda ventana de la terminal, inicia ot-ctl:
$ sudo ./build/posix/src/posix/ot-ctl >
Verifica el state del nodo 2 (el nodo RCP) que comenzaste con ot-daemon:
> state disabled Done
5. Cómo configurar los FTD
Los otros dos nodos de Thread que se usan en este Codelab son dispositivos de subproceso completo (FTD) en el diseño estándar del sistema en chip (SoC). En una configuración de producción, es posible que se use wpantund, un controlador de interfaz de red de nivel de producción, para controlar instancias NCP de OpenThread, pero en este codelab usaremos ot-ctl, la CLI de OpenThread.
Un dispositivo funciona como Comisionado para autenticar y comisionar dispositivos en esa red de forma segura. El otro dispositivo funciona como un Joiner que el comisionado puede autenticar en la red de Thread.
Compilación y escritura en la memoria flash
Compila el ejemplo de FTD de OpenThread para la plataforma nRF52840 con las funciones de Comisionado y Unión:
$ cd ~/src/ot-nrf528xx $ rm -rf build $ script/build nrf52840 USB_trans -DOT_JOINER=ON -DOT_COMMISSIONER=ON
Navega al directorio con el objeto binario de la CLI de OpenThread Thread Device (FTD) y conviértelo al formato hexadecimal:
$ cd ~/src/ot-nrf528xx/build/bin $ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex
Conecta el cable USB al puerto micro USB que se encuentra junto al pin de alimentación externo de la placa nRF52840 y, luego, conéctalo a la máquina Linux. Si el RCP sigue conectado a la máquina Linux, esta debe aparecer como el puerto en serie /dev/ttyACM1 (todas las placas nRF52840 usan ttyACM para el identificador del puerto en serie).
$ ls /dev/ttyACM* /dev/ttyACM0 /dev/ttyACM1
Como antes, observa el número de serie de la placa nRF52840 que se usa para el FTD:
Navega a la ubicación de las herramientas de línea de comandos nRFx y escribe el archivo hexadecimal CLI FTD de OpenThread en la placa nRF52840 con el número de serie de la placa:
$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
~/src/ot-nrf528xx/build/bin/ot-cli-ftd.hex --reset
Etiqueta la pizarra como "Commissioner".
Conectar a USB nativo
Debido a que la compilación del FTD de OpenThread permite el uso de ACM nativo de CDC por USB como transporte en serie, debes usar el puerto USB de nRF en la placa nRF52840 para comunicarte con el host de RCP (máquina Linux).
Desconecta el extremo micro-USB del cable USB del puerto de depuración de la placa nRF52840 parpadeante y, luego, vuelve a conectarlo al puerto micro-USB nRF USB junto al botón RESTABLECER. Establece el interruptor de Fuente de alimentación nRF en USB.
Verifica la compilación
Verifica una compilación exitosa accediendo a la CLI de OpenThread con GNU Screen desde una ventana de terminal. Las placas nRF52840 usan una velocidad de baud de 115200.
$ screen /dev/ttyACM1 115200
En la ventana nueva, presiona Intro en el teclado varias veces para que aparezca el mensaje > de la CLI de OpenThread. Abre la interfaz de IPv6 y busca direcciones:
> ifconfig up Done > ipaddr fe80:0:0:0:1cd6:87a9:cb9d:4b1d Done
Usar Ctrl + a →
d para desconectarte de la pantalla del CLI Commissioner de FTD y volver a la terminal de Linux para que se pueda escribir en la memoria flash de la siguiente placa. Para volver a ingresar la CLI en cualquier momento, usa screen -r desde la línea de comandos. Para ver la lista de pantallas disponibles, usa screen -ls:
$ screen -ls
There is a screen on:
74182.ttys000.mylinuxmachine (Detached)
1 Socket in /tmp/uscreens/S-username.
Configure el unión del FTD
Repite el proceso anterior para escribir en la memoria flash la tercera placa nRF52840 con la compilación ot-cli-ftd.hex existente. Cuando termines, asegúrate de volver a conectar la placa a la PC con el puerto USB nRF y establece el interruptor de Fuente de alimentación nRF en VDD.
Si los otros dos nodos están conectados a la máquina Linux cuando se conecta esta tercera placa, debe aparecer como puerto en serie /dev/ttyACM2:
$ ls /dev/ttyACM* /dev/ttyACM0 /dev/ttyACM1 /dev/ttyACM2
Etiqueta la pizarra como “Unión”.
Cuando realice la verificación con Screen, en lugar de crear una nueva instancia de Screen desde la línea de comandos, vuelva a conectarse a la existente y cree una nueva ventana dentro de ella (que utilizó para el comisionado de FTD):
$ screen -r
Para crear la ventana nueva en Pantalla, presiona Ctrl + a → c.
Aparecerá una nueva ventana de la línea de comandos. Acceda a la CLI de OpenThread para el FTD Joiner:
$ screen /dev/ttyACM2 115200
En esta nueva ventana, presiona Intro en el teclado varias veces para que aparezca el mensaje > de la CLI de OpenThread. Abre la interfaz de IPv6 y busca direcciones:
> ifconfig up Done > ipaddr fe80:0:0:0:6c1e:87a2:df05:c240 Done
Ahora que la CLI de Joint FTD se encuentra en la misma instancia de Screen que el comisionado de FTD, puedes cambiar entre ellas con Ctrl+a → n.
Usar Ctrl + a →
d en cualquier momento para salir de Pantalla.
6. Configuración de la ventana de terminal
En el futuro, cambiarás entre dispositivos Thread con frecuencia, así que asegúrate de que todos estén activos y de fácil acceso. Hasta ahora, usamos la pantalla para acceder a los dos FTD y esta herramienta también permite usar la pantalla dividida en la misma ventana de la terminal. Use esta información para ver cómo reacciona un nodo a los comandos emitidos en otro.
Lo ideal es que tengas cuatro ventanas disponibles:
- Registros o servicio de
ot-daemon - Unión de RCP por medio de
ot-ctl - Comisionado de FTD mediante la CLI de OpenThread
- Unión de FTD mediante la CLI de OpenThread
Si deseas usar tu propia configuración o herramienta de puertos en serie / terminal, puedes pasar al siguiente paso. Configura las ventanas de la terminal para todos los dispositivos de la manera que te resulte más conveniente.
Usando pantalla
Para facilitar su uso, solo inicia una sesión de Screen. Ya debería tener una cuando haya configurado ambos FTD.
Todos los comandos que aparecen en pantalla comienzan con Ctrl+a.
Comandos básicos de la pantalla:
Vuelve a conectarte a la sesión de Screen (desde la línea de comandos). |
|
Salir de la sesión de pantalla | Ctrl+a → |
Crear ventana nueva dentro de la sesión de pantalla | Ctrl+a → |
Alternar entre ventanas en la misma sesión de pantalla | Ctrl+a → |
Cerrar la ventana actual de la sesión de pantalla | Ctrl+a → |
Pantalla dividida
Con la pantalla, puedes dividir la terminal en varias ventanas:
Para acceder a los comandos de screen, usa Ctrl+a. Todos los comandos deben comenzar con esta combinación de claves de acceso.
Si seguiste exactamente el Codelab, deberías tener dos ventanas (Comisionado de FTD, Unión de FTD) en la misma instancia de Pantalla. Para dividir la pantalla entre ambas, primero debes ingresar tu sesión de pantalla existente:
$ screen -r
Debes estar en uno de los dispositivos FTD. Sigue estos pasos en pantalla:
- Ctrl+a →
Spara dividir la ventana horizontalmente - Ctrl+a →
Tabpara mover el cursor a la nueva ventana en blanco - Ctrl+a →
npara cambiar a la siguiente ventana nueva - Si es igual que la ventana superior, vuelva a presionar Ctrl + a →
npara ver el otro dispositivo con FTD.
Ahora, ambas son visibles. Para alternar entre ellas, usa Ctrl + a → Tab. Se recomienda que cambies el título de cada ventana con Ctrl + a → A para evitar confusiones.
Uso avanzado
Para dividir aún más la pantalla en cuadrantes y ver los registros ot-daemon y la unión de RCP ot-ctl, esos servicios deben iniciarse dentro de esta misma instancia de pantalla. Para ello, detén ot-daemon y sal de ot-ctl, y reinícialo en las nuevas ventanas de pantalla (Ctrl + a → c).
Esta configuración no es obligatoria y se deja como un ejercicio para el usuario.
Usa los siguientes comandos para dividir y navegar entre ventanas:
Crear ventana nueva | Ctrl+a → |
Dividir ventana verticalmente | Ctrl+a → |
Dividir ventana horizontalmente | Ctrl+a → |
Ir a la siguiente ventana | Ctrl+a → |
Avanzar o retroceder la ventana que se muestra | Ctrl+a → |
Cambiar el nombre de la ventana actual | Ctrl+a → |
Puedes salir de la pantalla en cualquier momento con Ctrl + a → d y volver a adjuntarlo con screen -r desde la línea de comandos.
Para obtener más información sobre la pantalla, consulta la referencia rápida de la pantalla de GNU.
7. Cómo crear la red de Thread
Ahora que ya configuraste todas las ventanas y pantallas de la terminal, creemos nuestra red Thread. En el Comisionado de FTD, cree un nuevo conjunto de datos operativo y confírmelo como el activo. El conjunto de datos operativo es la configuración de la red Thread que estás creando.
## 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
Anota la clave de red 1234c0de7ab51234c0de7ab51234c0de, que usarás más adelante.
Confirme este conjunto de datos como el activo:
> dataset commit active Done
Abre la interfaz IPv6:
> ifconfig up Done
Inicia la operación del protocolo Thread:
> thread start Done
Después de un momento, verifica el estado del dispositivo. Debe ser el líder. También obtén el RLOC16 para referencia futura.
## FTD Commissioner ## ---------------------- > state leader Done > rloc16 0c00 Done
Verifica las direcciones IPv6 del dispositivo:
## 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)
La red "codelab" ahora es visible cuando se analiza desde otros dispositivos Thread.
Desde ot-ctl en Unión de RCP:
## RCP Joiner ## ---------------- > scan | PAN | MAC Address | Ch | dBm | LQI | +------+------------------+----+-----+-----+ | c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |
Desde la CLI de OpenThread en el unión del FTD:
## FTD Joiner ## ---------------- > scan | PAN | MAC Address | Ch | dBm | LQI | +------+------------------+----+-----+-----+ | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |
Si la red "codelab" no aparece en la lista, vuelve a intentarlo.
8. Agrega el RCP Joiner
La asignación de Thread no está activa en la red, por lo que necesitaremos agregar el RCP Joiner a la red Thread que acabamos de crear con un proceso de asignación fuera de banda.
En el Comisionado de FTD, anotamos la clave de red, por ejemplo 1234c0de7ab51234c0de7ab51234c0de. Si necesitas volver a buscar la clave de red, ejecuta el siguiente comando en el comisionado de FTD:
## FTD Commissioner ## > dataset networkkey 1234c0de7ab51234c0de7ab51234c0de Done
Luego, en el Junta de RCP, establezca su clave de red activa del conjunto de datos en la Clave de red del comisionado de FTD:
## RCP Joiner ## ---------------- > dataset networkkey 1234c0de7ab51234c0de7ab51234c0de Done > dataset commit active Done
Verifica el conjunto de datos para asegurarte de que esté configurado correctamente.
## RCP Joiner ## ---------------- > dataset Network Key: 1234c0de7ab51234c0de7ab51234c0de
Abre Thread para que la unión del RCP se una a la red de “codelab”. Espera unos segundos y verifica el estado, RLOC16 y sus direcciones 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
Anota la dirección IPv6 de la malla local (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f aquí), ya que la usarás más adelante.
En el comisionado de FTP, revise las tablas secundarias y el router para confirmar que ambos dispositivos forman parte de la misma red. Usa el RLOC16 para identificar el unión del 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
Haga ping a la dirección de la malla local del Unión del RCP (la dirección en malla local que se obtuvo del resultado del ipaddr de la Unión del RCP) para verificar la conectividad:
## 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
Ahora tenemos una red Thread que consta de dos nodos, ilustrada en este diagrama de topología:
Diagramas de topología
A medida que trabajes en el resto del codelab, mostraremos un nuevo diagrama de topología de Thread siempre que cambie el estado de la red. Las funciones de nodo se denotan de la siguiente manera:
Los routers siempre son pentágonos y los dispositivos finales son siempre círculos. Los números en cada nodo representan el ID del router o el ID secundario que se muestran en el resultado de la CLI, según el rol y el estado actual de cada nodo en ese momento.
9. Delegar la unión del FTD
Agreguemos el tercer dispositivo de Thread a la red "codelab". Esta vez, usaremos el proceso de comisionado en banda más seguro y solo permitiremos que se una el FTD.
En el unión del FTD, obtén el eui64 para que el comisionado de FTD pueda identificarlo:
## FTD Joiner ## ---------------- > eui64 2f57d222545271f1 Done
En el comisionado de FTD, inicia el comisionado y especifica el eui64 del dispositivo que puede unirse, junto con la credencial de unión, por ejemplo, J01NME. La credencial de unión es una string específica del dispositivo compuesta por todos los caracteres alfanuméricos en mayúsculas (0-9 y A-Y, excepto I, O, Q y Z para facilitar la lectura), con una longitud de entre 6 y 32 caracteres.
## FTD Commissioner ## ---------------------- > commissioner start Done > commissioner joiner add 2f57d222545271f1 J01NME Done
Cambie al unión del FTD. Inicie el rol de unión con la credencial de Joiner que acaba de configurar en el comisionado de FTD:
## FTD Joiner ## ---------------- > ifconfig up Done > joiner start J01NME Done
En el transcurso aproximado de un minuto, recibirá una confirmación de una autenticación exitosa:
## FTD Joiner ## ---------------- > Join success
Abra Thread para que el FTD Joiner se una a la red de "codelab" y compruebe inmediatamente el estado y RLOC16:
## FTD Joiner ## ---------------- > thread start Done > state child Done > rloc16 0c02 Done
Verifica las direcciones IPv6 del dispositivo. Tenga en cuenta que no hay ALOC. Eso se debe a que este dispositivo no es el líder ni a tener un rol específico de Anycast que requiera un 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)
Cambia inmediatamente al Comisionado de FTD y verifica las tablas secundarias y del router para confirmar que existen tres dispositivos en la red de "codelab":
## 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
Según la RLOC16, la unión FTD se adjuntó a la red como dispositivo final (secundario). Esta es nuestra topología actualizada:
10. Subproceso en acción
Los dispositivos Thread de este Codelab son un tipo específico de Dispositivo de hilo completo (FTD) llamado Dispositivo Final Apto para Router (REED). Esto significa que pueden funcionar como routers o dispositivos finales y pueden ascender de un dispositivo final a un router.
Thread puede admitir hasta 32 routers, pero intenta mantener la cantidad de routers entre 16 y 23. Si un REED se conecta como un dispositivo final (secundario) y la cantidad de routers es inferior a 16, después de un período aleatorio de dos minutos se promocionará automáticamente como router.
Si tenía dos elementos secundarios en su red de Thread después de agregar el conector de FTD, espere al menos dos minutos y vuelva a verificar el router y las tablas secundarias del comisionado de FTD:
## 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
El FTD Joiner (Extended MAC = e6cdd2d93249a243) se ascendió a un router. Ten en cuenta que el RLOC16 es diferente (b800 en lugar de 0c02), ya que el RLOC16 se basa en el ID del router y el ID secundario de un dispositivo. Cuando realiza la transición de un dispositivo final al router, los valores del ID de router y del ID secundario cambian, y también lo hace el RLOC16.
Confirme el estado nuevo y RLOC16 en el unión del FTD:
## FTD Joiner ## ---------------- > state router Done > rloc16 b800 Done
Cambiar el FTD Joiner
Para probar este comportamiento, puedes cambiar el unificador de FTD de forma manual de un router a un dispositivo final. Cambia el estado a secundario y verifica el RLOC16:
## FTD Joiner ## ---------------- > state child Done > rloc16 0c03 Done
En el comisionado de FTD, ahora el ensamblador de FTD debería aparecer en la tabla secundaria (ID = 3). Incluso puede estar en ambas durante la transición:
## 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
Después de un tiempo, se volverá a cambiar a un router con un RLOC de b800.
Quita al líder
El líder es elegido entre todos los routers de subprocesos. Esto significa que, si se quita al líder actual de la red de Thread, uno de los otros routers se convertirá en el nuevo líder.
En el Comisionado de FTD, cierra Thread para quitarlo de la red de Thread:
## FTD Commissioner ## ---------------------- > thread stop Done > ifconfig down Done
En dos minutos, FTD Joiner se convierte en el nuevo líder de Thread. Verifica el estado y las direcciones IPv6 del unión del FTD para verificar lo siguiente:
## 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
Verifica la tabla secundaria. Observa que hay un nuevo RLOC16. Este es el RCP Joiner, como lo indican el ID y la MAC extendida. Para mantener juntos la red Thread, cambió los routers superiores del FTD Commissioner al FTD. Esto da como resultado un nuevo RLOC16 para el RCP Joiner (porque su ID de router cambió de 3 a 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
Es posible que deba esperar unos minutos para que el unión RCP se conecte al vinculador FTD cuando era secundario. Verifica el estado y el RLOC16 para confirmar lo siguiente:
## RCP Joiner ## -------------- > state child > rloc16 b801
Vuelve a conectar el comisionado de FTD
Una red Thread con dos nodos no es muy divertido. Volvamos a poner al comisionado de FTD en línea.
En el Comisionado de FTD, reinicia Thread:
## FTD Commissioner ## ---------------------- > ifconfig up Done > thread start Done
En dos minutos, se vuelve a conectar automáticamente a la red "codelab" como un dispositivo final y luego se promociona a sí mismo en un router.
## FTD Commissioner ## ---------------------- > state router Done
Revise las tablas secundarias y del router en el unión del FTD para verificar lo siguiente:
## 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
Nuestra red de Thread consta de tres nodos de nuevo.
11. Solución de problemas
Administrar una red Thread con varios dispositivos en diferentes terminales o ventanas de pantalla puede ser complicado. Usa estas sugerencias para "restablecer" el estado de la red o de tu lugar de trabajo si tienes problemas.
Pantalla
Si alguna vez te pierdes la configuración (demasiadas ventanas de pantalla o pantallas dentro de la pantalla), continúa finalizando las ventanas de pantalla con Ctrl + a → k hasta que no exista ninguna y screen -ls en la línea de comandos genera No Sockets found. Luego, vuelve a crear las ventanas de pantalla para cada dispositivo. Los estados del dispositivo se retienen incluso cuando se cierra la pantalla.
Nodos de subprocesos
Si la topología de la red Thread no se describe en este Codelab o los nodos se desconectan por algún motivo (tal vez porque la máquina Linux que los está apagando), se recomienda desconectar Thread, borrar las credenciales de la red y volver a comenzar desde el paso Create the Thread network.
Para restablecer el FTD, haz lo siguiente:
## FTD Commissioner or FTD Joiner ## ------------------------------------ > thread stop Done > ifconfig down Done > factoryreset Done
El RCP se puede restablecer de la misma manera a través de ot-ctl:
## RCP Joiner ## ---------------- > thread stop Done > ifconfig down Done > factoryreset Done
12. Uso de la multidifusión
La multidifusión se usa para comunicar información a un grupo de dispositivos a la vez. En una red Thread, las direcciones específicas se reservan para uso multidifusión con diferentes grupos de dispositivos, según el alcance.
Dirección IPv6 | Alcance | Entregado a |
| Vínculo local | Todos los FTD y MED |
| Vínculo local | Todos los FTD y routers de borde |
| Malla local | Todos los FTD y MED |
| Malla local | Todos los FTD y routers de borde |
Debido a que no usamos un router de borde en este Codelab, nos enfocaremos en las dos direcciones de multidifusión del FTD y el MED.
Vínculo local
El alcance de vínculo local incluye todas las interfaces de Thread a las que se puede acceder mediante una sola transmisión de radio o un solo “salto”. La topología de red determina qué dispositivos responden a un ping a la dirección de multidifusión ff02::1.
Haz ping en ff02::1 desde el comisionado de FTD:
## FTD Commissioner ## ---------------------- > ping ff02::1 > 8 bytes from fe80:0:0:0:e4cd:d2d9:3249:a243: icmp_seq=2 hlim=64 time=9ms
Existen otros dos dispositivos en la red (unión FTD y unión RCP), pero el Comisionado de FTD solo recibió una respuesta de la Dirección de vínculo local (LLA) del FTD. Esto significa que el FTD Joiner es el único dispositivo al que el comisionado de FTD puede alcanzar con un solo salto.
Ahora haga ping a ff02::1 desde el unión del FTD:
## 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
Dos respuestas. Si verificamos las direcciones IPv6 de los otros dispositivos, podemos ver que el primero (que termina en 4b1d) es el LLA del comisionado de FTD y el segundo (que termina en 943b) es el LLA del ensamblador de RCP.
Esto significa que el FTD Joiner está conectado directamente tanto con el FTD Commissioner como con el RCP Joiner, lo que confirma nuestra topología.
Malla local
El alcance Mesh-Local incluye todas las interfaces de Thread a las que se puede acceder dentro de la misma red de Thread. Veamos las respuestas a un ping a la dirección de multidifusión ff03::1.
Haz ping en ff03::1 desde el comisionado de 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
Esta vez, el comisionado de FTD recibió dos respuestas, una del Localizador de rutas del comparador de FTD (RLOC, que termina en b800) y otra del EID de la malla local del ensamblador de RCP (ML-EID, que termina en d55f). Esto se debe a que el alcance local de la malla abarca toda la red de Thread. No importa en qué parte de la red se encuentre un dispositivo, estará suscrito a la dirección ff03::1.
Haz ping en ff03::1 desde el combinador de FTD para confirmar el mismo comportamiento:
## 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
Observa el tiempo de respuesta del RCP Joiner en ambos resultados de ping. El RCP Joiner tardó mucho más en llegar al comisionado de FTD (68 ms) que lo hizo en el FTD Joiner (23 ms). Esto se debe a que tiene que hacer dos saltos para llegar al comisionado de la FTD, en comparación con uno para el Unión del FTD.
Es posible que también hayas notado que el ping de multidifusión local de la malla respondió con el RLOC solo para los dos FTD, no para el RCP Joiner. Esto se debe a que los FTD son routers dentro de la red, mientras que el RCP es un dispositivo final.
Compruebe el estado del Unión de RCP para confirmar:
## RCP Joiner ## ---------------- > state child
13. Envía mensajes con UDP
Uno de los servicios de aplicación que proporciona OpenThread es el protocolo de datagramas de usuario (UDP), un protocolo de capa de transporte. Una aplicación compilada en OpenThread podría usar la API de UDP para pasar mensajes entre nodos de una red de Thread o para otros dispositivos en una red externa (como Internet, si la red de Thread cuenta con un router de borde).
Los sockets UDP se exponen a través de la CLI de OpenThread. Vamos a usarlo para pasar mensajes entre los dos FTD.
Obtén la dirección de EID local de la malla para el unión del FTD. Usamos esta dirección porque se puede acceder desde cualquier lugar de la red 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
Inicia UDP y vincúlalo a un socket para cualquier dirección IPv6:
## FTD Joiner ## ---------------- > udp open Done > udp bind :: 1212
Cambie al Comisionado de FTP, inicie UDP y conéctese al socket que configuró en el conector de FTD, mediante su ML-EID:
## FTD Commissioner ## ---------------------- > udp open Done > udp connect fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd 1212 Done
La conexión UDP debe estar activa entre los dos nodos. Envía un mensaje del comisionado de la FTD:
## FTD Commissioner ## ---------------------- > udp send hellothere Done
En el Unión de FTD, se recibió el mensaje UDP.
## FTD Joiner ## ---------------- > 10 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00 49153 hellothere
14. Felicitaciones
Creaste una red Thread física.
Ahora sabe lo siguiente:
- la diferencia entre los tipos, las funciones y los permisos de los dispositivos de Thread
- cómo administran los dispositivos Thread sus estados dentro de la red
- Cómo pasar mensajes simples entre nodos mediante UDP
Próximos pasos
A partir de este codelab, prueba los siguientes ejercicios:
- Vuelve a escribir la placa de unión de FTD como MTD con el objeto binario
ot-cli-mtdy observa que nunca se actualiza a un router o intenta convertirse en líder - Agrega más dispositivos (prueba una plataforma diferente) a la red y esboza la topología con tablas secundarias y routers, junto con pings a las direcciones de multidifusión.
- Usa pyspinel para controlar el NCP
- Convierte el NCP en un router de borde mediante el router de borde de Thread y conecta tu red de Thread a Internet
Lecturas adicionales
Consulta openthread.io y GitHub para obtener una variedad de recursos de OpenThread, incluidos los siguientes:
- Plataformas compatibles: Descubre todas las plataformas compatibles con OpenThread
- Compilación de OpenThread: Más detalles sobre la compilación y configuración de OpenThread
- Primer de Thread: Abarca todos los conceptos de Thread que se incluyen en este Codelab.
Referencia: