Se usó la API de Cloud Translation para traducir esta página.

Cómo crear una red Thread con placas nRF52840 y OpenThread

1. Introducción

OpenThread, lanzado por Google, es una implementación de código abierto del protocolo de red Thread®. Google Nest lanzó OpenThread para poner a disposición de los desarrolladores la tecnología que se usa en los productos Nest a 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, confiable, seguro y de bajo consumo basado en IPv6 para las aplicaciones del hogar. OpenThread implementa todas las capas de herramientas de redes de Thread, incluidas IPv6, 6LoWPAN, IEEE 802.15.4 con seguridad MAC, establecimiento de vínculos de malla y enrutamiento de malla.

En este Codelab, debes programar OpenThread en hardware real, crear y administrar una red Thread, y pasar mensajes entre nodos.

Qué aprenderás

Compila y escribe objetos binarios de la CLI de OpenThread en placas de desarrollo
Compila un RCP que consiste en una máquina Linux y una placa de desarrollo
Cómo comunicarse con un RCP mediante OpenThread Daemon y ot-ctl
Cómo administrar nodos de Thread de forma manual con la pantalla GNU y la CLI de OpenThread
Puesta en marcha segura de los dispositivos en una red Thread
Cómo funciona la multidifusión IPv6
Pasa mensajes entre nodos Thread con UDP

Requisitos

Hardware:

3 placas de desarrollo nRF 52840 nórdicos de semiconductores
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 nórdicas nRF5x
Software Segger J-Link
OpenThread
Git

2. Cómo comenzar

Simulación de OpenThread

Antes de comenzar, te recomendamos ejecutar 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. Este Codelab usa GNU Screen y proporciona una descripción general de uso, pero se puede usar cualquier otro software de terminal.

Máquina Linux

Este Codelab fue diseñado para usar una máquina Linux basada en i386 o x86 a fin de que funcione como host de un dispositivo Thread de radioprocesador (RCP) y para instalar todas las placas de desarrollo de Thread. Todos los pasos se probaron en Ubuntu 14.04.5 LTS (Trusty Tahr).

Placas nr55880 de Nordic Semiconductor

Este Codelab usa tres placas nRF52840 de PDK.

Instalar SEGGER J-Link

Utilizamos SEGGER J-Link para programar las placas nRF52840, que tienen módulos JTAG integrados. Instala esto en tu máquina Linux.

Descarga el paquete adecuado para tu máquina e instálalo en la ubicación correcta. En Linux, es /opt/SEGGER/JLink.

Instala las herramientas de línea de comandos de 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> 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 las 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 pantalla, pero puedes usar cualquier aplicación de terminal de puerto en serie que desees.

$ sudo apt-get install screen

3. Clonar 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 el daemon de OpenThread:

$ script/cmake-build posix -DOT_DAEMON=ON

Ya estás listo para crear e instalar OpenThread en las placas nRF52840.

4. Configura el RCP Joiner

Compila y escribe en la memoria flash

Compila el ejemplo nRF52840 de OpenThread con la unión y la funcionalidad de USB nativo. Un dispositivo usa la función de Joiner para autenticarse y ponerse en marcha de forma segura en una red Thread. El puerto USB nativo permite el uso de USB CDC ACM 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 de OpenThread RCP y conviértelo a 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 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 nRF de la placa nRF52840 en VDD. Cuando se conecta correctamente, LED5 está activada.

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 a la ubicación de las herramientas de línea de comandos nRFx e instala el archivo hexadecimal RCP de OpenThread en la placa nRF52840 con el número de serie de la placa. Ten en cuenta que si omites la marca --verify, verás un mensaje de advertencia que te 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 con éxito:

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 el tablero "RCP" para que luego no confundas los roles del tablero.

Conectar a USB nativo

Debido a que la compilación RCP de OpenThread permite el uso de ACM CDC USB nativos como transporte en serie, debes usar el puerto nRF USB en la placa nRF52840 para comunicarte con el host RCP (máquina Linux).

Desconecta el extremo micro-USB del cable USB del puerto de depuración de la placa nRF52840 en la memoria flash y, luego, vuelve a conectarlo al puerto micro-USB nRF USB junto al botón RESTABLECER. Establece la opción nRF power source en USB.

Iniciar OpenThread Daemon

En el diseño de RCP, usa el Daemon de OpenThread para comunicarte con el dispositivo Thread y administrarlo. Inicia ot-daemon con la marca detallada -v para 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 el 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 la 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 de Thread simulados.

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 de sistema en chip (SoC). En una configuración de producción, se podría usar wpantund, un controlador de interfaz de red de nivel de producción, para controlar las instancias de NCP de OpenThread, pero en este codelab, usaremos ot-ctl, la CLI de OpenThread.

Un dispositivo funciona como comisionado para autenticar y autenticar los dispositivos en esa red de forma segura. El otro dispositivo funciona como un Unión que el Comisionado puede autenticar en la red Thread.

Compila y escribe en la memoria flash

Compila el ejemplo de FTD de OpenThread para la plataforma nRF52840 con las funciones de comisionado y comandante habilitadas:

$ cd ~/src/ot-nrf528xx
$ rm -rf build
$ script/build nrf52840 USB_trans -DOT_JOINER=ON -DOT_COMMISSIONER=ON

Ve al directorio con el objeto binario de la CLI de OpenThread Full Thread Device (FTD) y conviértelo a 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 está junto a la clavija de alimentación externa en la placa nRF52840 y, a continuación, conéctalo a la máquina Linux. Si el RCP sigue conectado a la máquina Linux, esta placa nueva debe aparecer como puerto en serie /dev/ttyACM1 (todas las placas nRF52840 usan ttyACM para el identificador de puerto en serie).

$ ls /dev/ttyACM*
/dev/ttyACM0  /dev/ttyACM1

Como antes, toma nota del 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 e instala el archivo hexadecimal FTD de CLI de OpenThread en la placa nRF52840 mediante 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 el tablero "Comisionado".

Conectar a USB nativo

Debido a que la compilación FTD de OpenThread permite el uso de ACM USB CDC USB nativos como transporte en serie, debes usar el puerto nRF USB en la placa nRF52840 para comunicarte con el host de RCP (máquina Linux).

Verificar compilación

Verifica una compilación exitosa accediendo a la CLI de OpenThread mediante la pantalla GNU desde una ventana de terminal. Las placas nRF52840 usan una velocidad en baudios 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 verifica las direcciones:

> ifconfig up
Done
> ipaddr
fe80:0:0:0:1cd6:87a9:cb9d:4b1d
Done

Usar Ctrl+a →

d para desconectarte de la pantalla de la CLI de Commissioner FTD y volver a la terminal de Linux para que se pueda instalar la siguiente placa. Para volver a ingresar la CLI en cualquier momento, usa screen -r desde la línea de comandos. Para ver una lista de las 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 FTD Joiner

Repite el proceso anterior para escribir en la memoria flash la tercera placa nRF52840 con la compilación ot-cli-ftd.hex existente. Cuando hayas terminado, 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 se conectan a la máquina Linux cuando se conecta esta tercera placa, deben aparecer como puerto en serie /dev/ttyACM2:

$ ls /dev/ttyACM*
/dev/ttyACM0  /dev/ttyACM1  /dev/ttyACM2

Etiquetar el tablero "Joiner"

Cuando realice la verificación mediante Screen, en lugar de crear una nueva instancia de Screen desde la línea de comandos, vuelva a adjuntar la existente y cree una nueva ventana dentro de ella (que utilizó para el Comisionado de FTD):

$ screen -r

Crea la ventana nueva en Pantalla con Ctrl+a → c.

Aparecerá una nueva línea de comandos. Accede a la CLI de OpenThread para el FTD Joiner:

$ screen /dev/ttyACM2 115200

En esta nueva ventana, presiona Volver en el teclado varias veces para que aparezca el mensaje > de la CLI de OpenThread. Abre la interfaz de IPv6 y verifica las direcciones:

> ifconfig up
Done
> ipaddr
fe80:0:0:0:6c1e:87a2:df05:c240
Done

Ahora que la CLI de FTD Joiner está en la misma instancia de Screen que el FTD Commissioner, puedes cambiar entre ellas con Ctrl+a → n.

Usar Ctrl+a →

d en cualquier momento para salir de la pantalla.

6. Configuración de la ventana de la terminal

De ahora en adelante, cambiarás entre los dispositivos Thread de forma frecuente, 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. Úselo 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 a través de ot-ctl
Comisionado de FTD mediante la CLI de OpenThread
Unión de FTD a través de la CLI de OpenThread

Si quieres usar tu propia configuración o herramienta de terminal o puerto en serie, puedes continuar con el siguiente paso. Configura las ventanas de la terminal para todos los dispositivos de la manera que te resulte más conveniente.

Uso de la pantalla

Para facilitar su uso, inicia solo una sesión de pantalla. Ya debería tener uno a partir de la configuración de ambos FTD.

Todos los comandos dentro de la pantalla comienzan con Ctrl+a.

Comandos básicos de pantalla:

Volver a adjuntar a la sesión de pantalla (desde la línea de comandos)	`screen -r`
Salir de la sesión de pantalla	Ctrl+a → `d`
Crear ventana nueva dentro de la sesión de pantalla	Ctrl+a → `c`
Alternar entre ventanas en la misma sesión de pantalla	Ctrl+a → `n` (adelante)Ctrl+a → `p` (atrás)
Cerrar la ventana actual de la sesión de pantalla	Ctrl+a → `k`

Pantalla dividida

Con la pantalla, puedes dividir la terminal en varias ventanas:

Para acceder a los comandos en screen, usa Ctrl+a. Todos los comandos deben comenzar con esta combinación de teclas de acceso.

Si seguiste el Codelab de forma exacta, deberías tener dos ventanas (FTD Commissioner y FTD Joiner) en la misma instancia de pantalla. Para dividir la pantalla entre ambos, primero ingresa tu sesión existente de Screen:

$ screen -r

Debes estar en uno de los dispositivos FTD. Sigue estos pasos en pantalla:

Ctrl+a → S para dividir la ventana horizontalmente
Ctrl+a → Tab para mover el cursor a la nueva ventana en blanco
Ctrl+a → n para cambiar a la siguiente ventana nueva
Si es igual a la ventana superior, presiona Ctrl + A → n para ver el otro dispositivo con FTD.

Ahora ambas son visibles. Para alternar entre ellas, presiona Ctrl + a → Tab. Se recomienda volver a nombrar 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 el RCP Joiner ot-ctl, esos servicios deben iniciarse en esta misma instancia de pantalla. Para ello, detén ot-daemon, sal de ot-ctl y reinícialo en 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 → `c`
Dividir ventana de forma vertical	Ctrl+a →
Dividir ventana horizontalmente	Ctrl+a → `S`
Ir a la siguiente ventana mostrada	Ctrl+a → `Tab`
Avanzar o retroceder la ventana que se muestra	Ctrl+a → `n` o `p`
Cambiar el nombre de la ventana actual	Ctrl+a → `A`

Puedes salir de la pantalla en cualquier momento con Ctrl+a → d y volver a adjuntarla 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 GNU.

7. Cómo crear la red Thread

Ahora que configuraste todas las ventanas y pantallas de 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

Toma nota de la clave de red 1234c0de7ab51234c0de7ab51234c0de que se usará más adelante.

Confirma este conjunto de datos como el activo:

> dataset commit active
Done

Abre la interfaz de 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 de &codet "codelab" ahora es visible cuando se analiza desde otros dispositivos de Thread.

Desde ot-ctl en el 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 de FTD:

## FTD Joiner ##
----------------

> scan
| PAN  | MAC Address      | Ch | dBm | LQI |
+------+------------------+----+-----+-----+
| c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |

Si la red &codet no aparece en la lista, vuelve a intentarlo.

8. Agrega el RCP Joiner

La ejecución de Thread no está activa en la red, lo que significa que tendremos que agregar el vinculador RCP a la red Thread que acabamos de crear con un proceso de puesta en marcha fuera de banda.

En el Comisionado de FTD, anotamos la clave de red, por ejemplo, 1234c0de7ab51234c0de7ab51234c0de. Si necesita volver a buscar la clave de red, ejecute el siguiente comando en FTD Commissioner:

## FTD Commissioner ##

> dataset networkkey
1234c0de7ab51234c0de7ab51234c0de
Done

A continuación, en RCP Joiner, establezca la clave de red del conjunto de datos activo como la clave de red del comisionado de FTD:

## RCP Joiner ##
----------------

> dataset networkkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

Comprueba el conjunto de datos para asegurarte de que esté configurado correctamente.

## RCP Joiner ##
----------------

> dataset
Network Key: 1234c0de7ab51234c0de7ab51234c0de

Abre Thread para que el RCP Joiner se una a la red de &code. Espera unos segundos, 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

Toma nota de la dirección IPv6 de malla local (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f aquí). 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 Conector de 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

Haz ping en la dirección de la red local de la RCP Joiner (la dirección de la malla local que se obtuvo del RCP Joiner ipaddr) 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, ilustrados en este diagrama de topología:

Diagramas de topología

A medida que trabajes con el resto del codelab, te mostraremos un nuevo diagrama de topología de Thread cada vez que cambie el estado de la red. Las funciones de los nodos se indican de la siguiente manera:

Los routers son siempre pentágonos y los dispositivos finales siempre son círculos. Los números de cada nodo representan el ID de router o secundario que se muestra en el resultado de la CLI, según la función y el estado actual de cada nodo en ese momento.

9. Delegar la vinculación al FTD

Ahora, agreguemos el tercer dispositivo Thread a la red de &code. Esta vez, usaremos el proceso de comisionado en banda más seguro, y solo permitiremos que se una el FTD Joiner.

En el unión de FTD, obtén la eui64 para que el comisionado de FTD pueda identificarla:

## FTD Joiner ##
----------------

> eui64
2f57d222545271f1
Done

En el Comisionado de FTD, inicie el comisionado y especifique 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 de todos los caracteres alfanuméricos en mayúsculas (0-9 y A-Y, excepto I, O, Q y Z para una mayor legibilidad), con una longitud de entre 6 y 32 caracteres.

## FTD Commissioner ##
----------------------

> commissioner start
Done
> commissioner joiner add 2f57d222545271f1 J01NME
Done

Cambie al conector de FTD. Inicie el rol de socio con la credencial de Unión que acaba de configurar en el Comisionado de FTD:

## FTD Joiner ##
----------------

> ifconfig up
Done
> joiner start J01NME
Done

Dentro de un minuto aproximadamente, recibirás una confirmación de una autenticación exitosa:

## FTD Joiner ##
----------------

>
Join success

Abre Thread para que el FTD Joiner se una a la red &codet; y verifica 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. Esto se debe a que este dispositivo no es el líder ni a tener una función Anycast específica que requiere 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 Codecode:

## 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 el RLOC16, el FTD Joiner se conectó a la red como un 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 subproceso completo (FTD) denominado dispositivo final apto (REED) del router. 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 convierte automáticamente en un router.

Si tenías dos hijos en tu red Thread después de agregar el FTD Joiner, espera al menos dos minutos y luego vuelve a verificar el router y las tablas secundarias en el 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

El FTD Joiner (MAC extendido = e6cdd2d93249a243) se ascendió a un router. Ten en cuenta que el RLOC16 es diferente (b800 en lugar de 0c02). Esto se debe a que el RLOC16 se basa en el ID del router y el ID secundario de un dispositivo. Cuando pasa del dispositivo final al router, sus valores de ID de router e ID de hijo también cambian, y también lo hace el RLOC16.

Confirma el estado nuevo y el RLOC16 en el unión de FTD:

## FTD Joiner ##
----------------

> state
router
Done
> rloc16
b800
Done

Cambiar el FTD Joiner

Para probar este comportamiento, cambia el unión 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

De regreso en Comisionado de FTD, ahora debería aparecer en la tabla secundaria (ID = 3). Incluso puede estar en ambos 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, volverá a cambiar a un router con un RLOC de b800.

Quitar al líder

El líder es electo entre todos los routers de subprocesos. Esto significa que si se quita al líder actual de la red Thread, uno de los otros routers se convertirá en el nuevo líder.

En FTD Commissioner, cierra Thread para quitarlo de la red Thread:

## FTD Commissioner ##
----------------------

> thread stop
Done
> ifconfig down
Done

Luego de dos minutos, el FTD Joiner se convierte en el nuevo líder del subproceso. Verifica el estado y las direcciones IPv6 del vinculador FTD para verificar:

## 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. Ten en cuenta que hay un nuevo RLOC16. Este es el RCP Joiner, como lo indican su ID y MAC extendido. Para mantener la red Thread, cambió los routers superiores, de FTD Commissioner a FTD Joiner. 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 tenga que esperar unos minutos para que el Unión de RCP se conecte con el FTD Joiner cuando era un niño. Verifica el estado y el RLOC16 para confirmar lo siguiente:

## RCP Joiner ##
--------------

> state
child
> rloc16
b801

Vuelva a adjuntar al comisionado de FTD

Una red Thread con dos nodos no es muy divertida. Volvamos a poner al Comisionado de FTD en línea.

En el Comisionado de FTD, reinicia el subproceso:

## FTD Commissioner ##
----------------------

> ifconfig up
Done
> thread start
Done

En dos minutos, se vuelve a conectar automáticamente a la red de "codelab" como dispositivo final y luego se asciende a un router.

## FTD Commissioner ##
----------------------

> state
router
Done

Revise las tablas secundarias y del router en la 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 Thread consta de tres nodos nuevamente.

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 tu lugar de trabajo si tienes problemas.

Pantalla

Si alguna vez te pierdes en la configuración (demasiadas ventanas de pantalla o pantallas dentro de la pantalla), continúa cerrando 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 conservan incluso cuando se cierra la pantalla.

Nodos de subprocesos

Si la topología de la red Thread no se describe como se describe en este Codelab o los nodos se desconectan por algún motivo (quizás porque la máquina Linux que los activó se suspendió), lo mejor es desconectar Thread, borrar las credenciales de la red y comenzar de nuevo desde el paso Create the Thread network.

Para restablecer las FTD:

## FTD Commissioner or FTD Joiner ##
------------------------------------

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

El RCP se puede restablecer de la misma manera mediante ot-ctl:

## RCP Joiner ##
----------------

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

12. Cómo usar 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 el uso de multidifusión con diferentes grupos de dispositivos, según el alcance.

Dirección IPv6	Ámbito	Entregado a
`ff02::1`	Vínculo local	Todos los FTD y MED
`ff02::2`	Vínculo local	Todos los FTD y routers perimetrales
`ff03::1`	Malla local	Todos los FTD y MED
`ff03::2`	Malla local	Todos los FTD y routers perimetrales

Debido a que no usamos un router de borde en este Codelab, concentrémonos en las dos direcciones de multidifusión FTD y MED.

Vínculo local

El alcance del 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 &hop. La topología de la red determina qué dispositivos responden a un ping a la dirección de multidifusión ff02::1.

Haga ping a 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

Hay otros dos dispositivos en la red (Unión de FTD y unificador de RCP), pero el Comisionado de FTD solo recibió una respuesta, de la Dirección de vínculo local (LLA) de FTD. Esto significa que el FTD Joiner es el único dispositivo al que el Comisionado de FTD puede llegar con un solo salto.

Ahora haga ping a ff02::1 desde el unión de 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! Al revisar 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 de RCP.

Esto significa que el FTD Joiner está conectado directamente al FTD Commissioner y al RCP Joiner, lo que confirma nuestra topología.

Malla local

El alcance de la malla local comprende todas las interfaces de Thread a las que se puede acceder dentro de la misma red Thread. Veamos las respuestas a un ping a la dirección de multidifusión ff03::1.

Haga ping a 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 la FTD recibió dos respuestas: una del localizador de rutas (RLOC) del FTD y otra del EID de la malla local (ML-EID, que termina en d55f). Eso se debe a que el alcance local de la malla abarca toda la red de Thread. Sin importar en qué parte de la red se encuentre un dispositivo, estará suscrito a la dirección ff03::1.

Haga ping a ff03::1 desde el unificador 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

Ten en cuenta el tiempo de respuesta para el RCP Joiner en ambas salidas de ping. El RCP Joiner tardó mucho más en llegar al FTD Commissioner (68 ms) que en llegar al FTD Joiner (23 ms). Eso se debe a que debe hacer dos saltos para llegar al comisionado de FTD, en comparación con uno para el FTD Joiner.

También es posible que 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 de la red, mientras que el RCP es un dispositivo final.

Verifica el estado de RCP Joiner 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 UDP para pasar mensajes entre nodos de una red Thread o para otros dispositivos en una red externa (como Internet, si la red Thread tiene un router de borde).

Los sockets UDP se exponen a través de la CLI de OpenThread. Úsalo para pasar mensajes entre los dos FTD.

Obtén la dirección EID local de la malla para el unión de FTD. Usamos esta dirección porque se puede acceder desde cualquier lugar dentro 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 a FTD Commissioner, inicie UDP y conéctese al socket que configuró en el vinculador 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 unido 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 física de Thread.

Ahora sabe lo siguiente:

la diferencia entre los tipos de dispositivo, las funciones y los alcances de Thread
cómo los dispositivos Thread administran 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 del FTD Joiner como un MTD con el objeto binario ot-cli-mtd y 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 de router, junto con pings a las direcciones de multidifusión.
Use pyspinel para controlar el NCP.
Convierte el NCP en un router de borde con OpenThread Border Router y conecta tu red Thread a Internet.

Lecturas adicionales

Consulte 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: Obtén más detalles sobre cómo compilar y configurar OpenThread
Thread Primer: Incluye todos los conceptos de Thread que aparecen en este Codelab.

Referencia: