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 redes Thread®. Google Nest lanzó OpenThread a fin de poner a disposición de los desarrolladores la tecnología que se usa en los productos Nest para acelerar el desarrollo de productos en el hogar conectado.

La especificación de Thread define un protocolo de comunicación entre dispositivos inalámbrico, confiable y seguro basado en IPv6 para las aplicaciones de la casa. OpenThread implementa todas las capas de red Thread, incluidas IPv6, 6LoWPAN, IEEE 802.15.4, con seguridad MAC, el establecimiento de vínculos de malla y el enrutamiento de mallas.

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

Qué aprenderás

Cómo compilar y escribir en la memoria flash objetos binarios de la CLI de OpenThread para placas de desarrollo
Cómo compilar un RCP que consta de una máquina Linux y una placa de desarrollo
Cómo comunicarse con un RCP mediante OpenThread Daemon y ot-ctl
Administración manual de nodos de Thread con GNU Screen y la CLI de OpenThread
Asignación de dispositivos segura a una red Thread
Cómo funciona la multidifusión IPv6
Pasa mensajes entre nodos de Thread con UDP

Requisitos

Hardware:

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

2. Comenzar

Simulación de OpenThread

Antes de comenzar, te recomendamos ejecutar el Codelab de simulaciones de OpenThread a fin de familiarizarte con los conceptos básicos de los subprocesos y la CLI.

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 se diseñó para usar una máquina con Linux basada en i386 o x86 a fin de que funcione como host en 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 de semiconductor nórdico nRF52840

Este codelab usa tres placas 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 con Linux.

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

Instala las herramientas de línea de comandos nRF5x

Las herramientas de línea de comandos nRF5x te permiten instalar los objetos binarios de OpenThread en las placas nRF52840. Instala la compilación nRF5x-Command-Line-Tools-<OS> en tu máquina de Linux.

Coloca el paquete que se extrajo en la carpeta raíz ~/.

Instalar la cadena de herramientas de GNU GNU

Se usa la cadena de herramientas ARM GNU para la compilación.

Recomendamos colocar el archivo extraído en el archivo /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 sencilla para acceder a dispositivos conectados por un puerto en serie. Este Codelab usa pantalla, 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 el daemon de OpenThread:

$ script/cmake-build posix -DOT_DAEMON=ON

Ya puedes compilar y escribir en la memoria flash OpenThread en las placas nRF52840.

4. Configura el RCP Joiner

Cómo compilar y escribir en la memoria flash

Compila el ejemplo de OpenThread nRF52840 con Joiner y funcionalidades nativas de USB. Un dispositivo usa la función de Joiner para autenticarse y comisionarse de forma segura en una red Thread. El puerto USB nativo permite el uso de USB CDC ACM como transporte en serie entre la 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 la fuente de alimentación nRF en la placa nRF52840 como VDD. Cuando se conecta de forma correcta, LED5 está activado.

Si es la primera placa conectada a la máquina Linux, aparece como el puerto en serie /dev/ttyACM0 (todas las placas nRF52840 usan ttyACM para el identificador del 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 y escribe 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, aparecerá un mensaje de advertencia que te indicará 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

La siguiente salida 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 panel (RCP) para que luego no confundas las funciones del tablero.

Conectar a USB nativo

Debido a que la compilación RCP de OpenThread permite el uso de ACM USB de CDC nativos como medio de 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 que se escribe en la memoria flash y, luego, vuelve a conectarlo al puerto micro-USB nRF USB junto al botón RESTABLECER. Configura el interruptor de fuente de alimentación nRF en USB.

Iniciar daemon de OpenThread

En el diseño del 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
$ ./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[228024]: Running OPENTHREAD/20191113-00831-gfb399104; POSIX; Jun  7 2020 18:05:15
ot-daemon[228024]: Thread version: 2
ot-daemon[228024]: RCP version: OPENTHREAD/20191113-00831-gfb399104; SIMULATION; Jun  7 2020 18:06:08

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 demás dispositivos Thread simulados.

En una segunda ventana de la terminal, inicia ot-ctl:

$ ./build/posix/bin/ot-ctl
>

Verifica el state del nodo 2 (el nodo RCP) que comenzaste con ot-daemon:

> state
disabled
Done

5. Configure los FTD

Los otros dos nodos de Thread que se usan en este codelab son dispositivos con subprocesos completos (FTD) en el diseño estándar de sistema en chip (SoC). En una configuración de producción, uno puede usar wpantund, un controlador de interfaz de red de nivel de producción, para controlar instancias de NCP de OpenThread, pero en este codelab usaremos ot-ctl, la CLI de OpenThread.

Un dispositivo funciona como el Comisionado para autenticar y asignar dispositivos a esa red de manera segura. El otro dispositivo funciona como un unión que el comisionado puede autenticar en la red de Thread.

Cómo compilar y escribir en la memoria flash

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

$ 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 CLI de subproceso completo de OpenThread (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 junto al pin de alimentación externo en la placa nRF52840 y, luego, conéctalo a la máquina Linux. Si el RCP todavía está conectado a la máquina Linux, debería aparecer la nueva placa como puerto de serie /dev/ttyACM1 (todas las placas nRF52840 utilizan ttyACM para el identificador de puerto en serie).

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

Al igual que antes, ten en cuenta 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

Etiquetar la junta (comisionador).

Conectar a USB nativo

Debido a que la compilación FTD de OpenThread permite el uso de ACM nativo de CDC USB como transporte en serie, debes usar el puerto nRF USB de 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 con la pantalla GNU desde una ventana de terminal. Las placas nRF52840 usan una velocidad en baud de 115200.

$ screen /dev/ttyACM1 115200

En la ventana nueva, presiona Volver en el teclado varias veces para que aparezca el mensaje > de la CLI de OpenThread. Abre la interfaz de IPv6 y busca 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 regresar a la terminal de Linux para que se pueda instalar la siguiente placa. Para volver a ingresar a la CLI en cualquier momento, usa screen -r en 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 de 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 de nRF y de que el interruptor de la fuente de alimentación de la red nRF sea 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

Etiquete el tablero "Joiner".

Cuando realices la verificación a través de Screen, en lugar de crear una nueva instancia de Screen desde la línea de comandos, vuelve a adjuntarlo a la existente y crea una nueva ventana dentro de ella (que utilizaste para el FTD Commissioner):

$ screen -r

Crea la ventana nueva dentro de la pantalla con Ctrl+a → c.

Aparecerá un nuevo símbolo del sistema de la línea de comandos. Acceda a la CLI de OpenThread para 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 busca 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 Comisionado de FTD, 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

En el futuro, cambiarás entre dispositivos Thread con frecuencia, así que asegúrate de que todos estén activos y se pueda acceder a ellos fácilmente. Hasta ahora, hemos usado Screen para acceder a los dos FTD y esta herramienta también permite dividir la pantalla en la misma ventana de terminal. Úselo para ver cómo reacciona un nodo a los comandos emitidos en otro.

Lo ideal sería que tengas cuatro ventanas disponibles:

Registros y 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 a través de CLI de OpenThread

Si deseas usar tu propia configuración o herramienta de puerto en serie o terminal, no dudes en avanzar al 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 Screen. Ya debe tener uno a la hora de configurar ambos FTD.

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

Comandos básicos de la pantalla:

Vuelve a adjuntar la sesión de pantalla (desde la línea de comandos).	`screen -r`
Salir de la sesión de pantalla	Ctrl+a → `d`
Crear una ventana nueva dentro de la sesión de pantalla	Ctrl+a → `c`
Cómo cambiar entre ventanas en la misma sesión de pantalla	Ctrl+a → `n` (adelante)Ctrl+a → `p` (atrás)
Elimina la ventana actual en 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 de screen, usa Ctrl+a. Cada comando debe comenzar con esta combinación de teclas de acceso.

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

$ screen -r

Debes usar 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 esa ventana nueva a la siguiente
Si es igual a la ventana superior, vuelve a presionar Ctrl + a → n para ver el otro dispositivo con FTD.

Ahora, ambas son visibles. Alterna entre ellas con Ctrl+a → Tab. Para evitar confusiones, se recomienda volver a nombrar cada ventana con Ctrl+a → A.

Uso avanzado

Para dividir aún más la pantalla en cuadrantes y ver los registros ot-daemon y la unión del RCP ot-ctl, esos servicios deben iniciarse dentro de la misma instancia de pantalla. Para ello, detén ot-daemon, sal de ot-ctl y reinícialo dentro de las nuevas ventanas de Screen (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 una ventana nueva	Ctrl+a → `c`
Dividir ventana de forma vertical	Ctrl+a →
Dividir ventana horizontalmente	Ctrl+a → `S`
Pasar a la siguiente ventana que se muestra	Ctrl+a → `Tab`
Cómo mover hacia delante o atrás 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 de GNU.

7. Crea la red Thread

Ahora que ya configuraste todas las ventanas y pantallas de la terminal, crearemos 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á 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.

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. Debería 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 &codet ahora es visible cuando se analiza desde otros dispositivos Thread.

Desde ot-ctl en el unión de RCP:

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

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |

Desde la CLI de OpenThread en el Joiner de FTD:

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

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |

Si la red no aparece en la lista, vuelve a buscarlo.

Tenga en cuenta que, en ambos análisis, la red no se puede unir (columna J en el combinador de RCP y FTD). Esto solo significa que Thread Commissioning no está activo en la red. Aún se puede unir fuera de banda ingresando la clave de red en el dispositivo de unión de forma manual.

8. Agrega el RCP Joiner

Agreguemos el RCP Joiner a la red Thread que acabamos de crear, mediante un proceso fuera de banda. Busca redes en Joiner de RCP:

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

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |

Para unirse, establece la clave de red (que acabamos de obtener del comisionado de FTD) en el RCP Joiner, en su conjunto de datos activo.

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

> dataset networkkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

Revisa 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 y comprueba el estado, RLOC16 y sus direcciones IPv6:

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

> 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 FTD, revisa las tablas secundarias y del router para confirmar que ambos dispositivos sean parte de la misma red. Usa el RLOC16 para identificar el combinador 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 malla local del RCP Joiner (la dirección de Mesh-Local que se obtuvo de la salida de la unión de RCP) 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, como se ilustra en este diagrama de topología:

Diagramas de topología

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

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

9. Comisión del FTD Joiner

Ahora, agreguemos el tercer dispositivo Thread a la red de &code. Esta vez, usaremos el proceso de puesta en marcha más seguro dentro de la banda. En FTD Joiner, busque la red:

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

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | f65ae2853ff0c4e4 | 11 | -36 |  57 |

Un 0 en la columna J indica que Thread Commissioning no está activo en el dispositivo.

Seremos específicos al momento de realizar la asignación en este próximo dispositivo y solo permitiremos que se una el FTD Joiner. Aún en la unión de FTD, obtén la eui64, para que el comisionado de FTD pueda identificarla:

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

> eui64
2f57d222545271f1
Done

En FTD Commissioner, inicia el encargado y especifica la eui64 del dispositivo que puede unirse, junto con la credencial de unión, por ejemplo, J01NME. La credencial de Joiner es una string específica de dispositivos con todos los caracteres alfanuméricos en mayúsculas (0-9 y A-Y, sin incluir 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 Joiner de FTD y vuelva a escanear:

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

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 1 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -45 | 196 |

Como se indica en 1 en la columna J, la asignación de subprocesos ahora está activa en la red. Inicie la función de unión con la credencial de unión que acaba de configurar en la comisión de FTD:

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

> ifconfig up
Done
> joiner start J01NME
Done

En el transcurso aproximado de un minuto, recibirás una confirmación de que la autenticación se realizó correctamente:

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

>
Join success

Abre Thread para que el Joiner FTD se una a la red de &code, y verifica de inmediato 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 un ALOC. Esto se debe a que este dispositivo no es el líder, y tampoco tiene 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 de inmediato al Comisionado de FTD y revisa las tablas secundarias y de router para confirmar que existen tres dispositivos en la red:

## 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) llamado dispositivo final apto para router (REED). Esto significa que pueden funcionar como un router o como dispositivo final, y pueden cambiar de un dispositivo final a uno.

Thread puede admitir hasta 32 routers, pero intenta mantener la cantidad de routers entre 16 y 23. Si se adjunta un REED como dispositivo final (secundario) y la cantidad de routers es inferior a 16, después de un período aleatorio dentro de dos minutos, se promocionará automáticamente a 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) 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 realiza la transición del dispositivo final al router, sus valores de ID de router y de ID secundario también cambian, como también el RLOC16.

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

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

> state
router
Done
> rloc16
b800
Done

Cambia el FTD Joiner

Para probar este comportamiento, puede cambiar a una versión inferior el Joiner de FTD 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 FTD Commissioner, el FTD Joiner debería aparecer ahora en la tabla secundaria (ID = 3). Incluso puede estar en ambas mientras se realiza 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 una RLOC de b800.

Quitar el 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 Thread, uno de los otros routers se convertirá en el nuevo líder.

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

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

> thread stop
Done
> ifconfig down
Done

En dos minutos, el FTD Joiner se convierte en el nuevo líder de Thread. Verifica el estado y las direcciones IPv6 del combinador de 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

Revise la tabla secundaria. Ten en cuenta que hay un nuevo RLOC16. Este es el RCP Joiner, como lo indican su ID y Extended MAC. Para mantener la red Thread juntas, 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 deba esperar algunos minutos para que el Joiner de RCP se una al FTD Joiner cuando sea secundario. Verifica el estado y el RLOC16 para confirmar lo siguiente:

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

> state
child
> rloc16
b801

Volver a adjuntar al comisionado de la 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 la conversación:

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

> ifconfig up
Done
> thread start
Done

En dos minutos, se vuelve a conectar automáticamente a la red de &code como un dispositivo final y luego se promociona a un router.

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

> state
router
Done

Revise las tablas secundarias y del router en el Joiner de 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 con tres nodos otra vez.

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 &ampular; el estado de la red o de tu lugar de trabajo si tienes problemas.

Pantalla

Si llegas a perder tu 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 de 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 (tal vez porque la máquina Linux que los activó) se suspende, lo mejor es desconectar Thread, borrar las credenciales de la red y volver a comenzar desde el paso Create the Thread network.

Para restablecer los 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. 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 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 fronterizos
`ff03::1`	Malla local	Todos los FTD y MED
`ff03::2`	Malla local	Todos los FTD y routers fronterizos

Debido a que no usamos un router de borde en este Codelab, enfoquémonos en las dos direcciones de multidifusión FTD y 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 único salto. La topología de red indica qué dispositivos responden a un ping a la dirección 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 (unidor de FTD y unidor de RCP), pero el Comisionado de FTD solo recibió una respuesta de la dirección de vínculo local (LLA) de FTD Joiner. 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 unido 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. Si verificamos las direcciones IPv6 de los otros dispositivos, podemos ver que el primero (que termina en 4b1d) es el Comisionado de FTD y el segundo (que termina en 943b) es el RCP Joiner.

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

Malla local

El alcance de la malla local incluye todas las interfaces de Thread a las que se puede acceder dentro de la misma red. Veamos las respuestas a un ping a la dirección 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 FTD recibió dos respuestas, una del localizador de rutas (RLOC) que termina en b800 y la del RCP y el EID (ML-EID, que finaliza 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 esté un dispositivo, estará suscrito a la dirección ff03::1.

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

Tenga en cuenta el tiempo de respuesta para el RCP Joiner en ambas salidas de ping. La unión del RCP tardó mucho más en llegar al comisionado de FTD (68 ms) que en llegar al comisionado de FTD (23 ms). Esto se debe a que tiene que dar dos saltos para llegar al comisionado de FTD en comparación con uno para el FTD Joiner.

Quizás hayas notado que el ping 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 las FTD son routers dentro de la red, mientras que el RCP es un dispositivo final.

Verifique 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 utilizar la API UDP para pasar mensajes entre nodos en una red Thread, o a otros dispositivos en una red externa (como Internet, si la red Thread presenta 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.

Obtenga la dirección EID de malla local para el unión de FTD. Utilizamos 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

Cambia al comisionado de FTD, inicia UDP y conéctate al socket que configuraste en el FTD Joiner, 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 desde la Comisión FTD:

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

> udp send hellothere
Done

En el Joiner 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 subprocesos.

Ahora sabe lo siguiente:

la diferencia entre los tipos de dispositivo, las funciones y los permisos 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 de FTD Joiner como un MTD con el objeto binario ot-cli-mtd y observa que nunca se actualice a un router o intente convertirse en el líder.
Agrega más dispositivos (prueba una plataforma diferente) a la red y esboza la topología mediante el router y las tablas secundarias, junto con pings a las direcciones de multidifusión.
Usa pyspinel para controlar el NCP
Convierte el NCP en un router de borde mediante OpenThread Border Router y conecta tu red 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
Build OpenThread: Obtén más detalles para compilar y configurar OpenThread
Thread Primer: Abarca todos los conceptos de Thread incluidos en este Codelab

Referencia: