O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Criar uma rede Thread com placas nRF52840 e OpenThread

1. Introdução

O OpenThread lançado pelo Google é uma implementação de código aberto do protocolo de rede Thread®. O Google Nest lançou o OpenThread para disponibilizar aos desenvolvedores a tecnologia usada nos produtos Nest para acelerar o desenvolvimento de produtos de casa conectada.

A especificação do Thread define um protocolo de comunicação entre dispositivos sem fio confiável, seguro e de baixo consumo de energia para aplicativos domésticos. O OpenThread implementa todas as camadas de rede Thread, incluindo IPv6, 6LoWPAN, IEEE 802.15.4 com segurança MAC, estabelecimento de link de malha e roteamento de malha.

Neste codelab, você vai programar o OpenThread em hardware real, criar e gerenciar uma rede Thread e transmitir mensagens entre nós.

O que você vai aprender

criar e atualizar binários da CLI OpenThread para placas de desenvolvimento
Criar um RCP composto por uma máquina Linux e uma placa de desenvolvimento
Como se comunicar com um RCP usando o Daemon do OpenThread e o ot-ctl
Como gerenciar manualmente nós do Thread com o GNU Screen e a CLI OpenThread
Comissionamento seguro de dispositivos em uma rede Thread
Como funciona o multicast IPv6
Como transmitir mensagens entre nós do Thread com UDP

O que é necessário

Hardware:

3 placas de desenvolvimento nórdicas nRF52840 de semicondutores
Três cabos USB para micro USB para conectar as placas
Um computador Linux com pelo menos três portas USB

Software:

Conjunto de ferramentas GNU
Ferramentas de linha de comando nórdicas nRF5x
Software Segger J-Link
OpenThread
Git

2. Primeiros passos

Simulação do OpenThread

Antes de começar, recomendamos executar o Codelab de simulação do OpenThread para se familiarizar com os conceitos básicos do Thread e a CLI do OpenThread.

Terminais de porta serial

Você precisa saber se conectar a uma porta serial usando um terminal. Este codelab usa o GNU Screen e oferece uma visão geral do uso, mas qualquer outro software de terminal pode ser usado.

Máquina Linux

Este codelab foi criado para usar uma máquina Linux baseada em i386 ou x86 para atuar como host de um dispositivo Thread de coprocessador de rádio (RCP, na sigla em inglês) e atualizar todas as placas de desenvolvimento de Thread. Todas as etapas foram testadas no Ubuntu 14.04.5 LTS (Trusty Tahr).

Placas de semicondutores nórdicos nRF52840

Este codelab usa três placas nRF52840 PDK.

Instalar o SEGGER J-Link

Usamos o SEGGER J-Link para programar as placas nRF52840, que têm módulos JTAG integrados. Instale na sua máquina Linux.

Faça o download do pacote adequado para sua máquina e instale-o no local adequado. No Linux, ele é /opt/SEGGER/JLink.

Como instalar as ferramentas de linha de comando nRF5x

As ferramentas de linha de comando nRF5x permitem que você atualize os binários do OpenThread nas placas nRF52840. Instale o nRF5x-Command-Line-Tools-<OS> apropriado. na sua máquina Linux.

Coloque o pacote extraído na pasta raiz ~/

Instalar o conjunto de ferramentas GNU ARM

O conjunto de ferramentas GNU ARM é usado para criação.

Recomendamos colocar o arquivo extraído em /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/ na sua máquina Linux. Siga as instruções no arquivo readme.txt do arquivo para instruções de instalação.

Tela de instalação (opcional)

O Screen é uma ferramenta simples para acessar dispositivos conectados por uma porta serial. Este codelab usa Screen, mas você pode usar qualquer aplicativo de terminal de porta serial que quiser.

$ sudo apt-get install screen

3. clonar repositórios

OpenThread

Clonar e instalar o OpenThread Os comandos script/bootstrap garantem que o conjunto de ferramentas esteja instalado e que o ambiente esteja configurado corretamente:

$ mkdir -p ~/src
$ cd ~/src
$ git clone --recursive https://github.com/openthread/openthread.git
$ cd openthread
$ ./script/bootstrap

Crie o daemon do OpenThread:

$ script/cmake-build posix -DOT_DAEMON=ON

Agora está tudo pronto para criar e atualizar o OpenThread para as placas nRF52840.

4. Configurar o Joiner do RCP

Criar e atualizar

Crie o exemplo do OpenThread nRF52840 com o Joiner e a funcionalidade USB nativa. Um dispositivo usa o papel de Joiner para ser autenticado e comissionado com segurança em uma rede Thread. O USB nativo permite o uso do USB CDC ACM como transporte serial entre o nRF52840 e o host.

Sempre limpe o repositório de builds anteriores primeiro executando rm -rf build.

$ cd ~/src
$ git clone --recursive https://github.com/openthread/ot-nrf528xx.git
$ cd ot-nrf528xx
$ script/build nrf52840 USB_trans

Navegue até o diretório com o binário RCP do OpenThread e converta-o para o formato hexadecimal:

$ cd ~/src/ot-nrf528xx/build/bin
$ arm-none-eabi-objcopy -O ihex ot-rcp ot-rcp.hex

Conecte o cabo USB à porta de depuração micro USB, ao lado do pino de alimentação externo na placa nRF52840, e conecte-o à máquina Linux. Defina a chave da fonte de alimentação nRF na placa nRF52840 como VDD. Quando conectado corretamente, o LED5 fica ligado.

Se essa for a primeira placa conectada à máquina Linux, ela aparecerá como porta serial /dev/ttyACM0 (todas as placas nRF52840 usam ttyACM para o identificador de porta serial).

$ ls /dev/ttyACM*
/dev/ttyACM0

Anote o número de série da placa nRF52840 usada para o RCP:

Navegue até o local das ferramentas de linha de comando nRFx e atualize o arquivo hexadecimal do OpenThread RCP na placa nRF52840, usando o número de série da placa. Se você deixar de fora a sinalização --verify, será exibida uma mensagem de aviso informando que o processo de flash pode falhar sem erros.

$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924  --verify --chiperase --program \
       ~/src/ot-nrf528xx/build/bin/ot-rcp.hex --reset

A saída a seguir será gerada após a conclusão:

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.

Marcar o quadro como "RCP" para não confundir as funções do conselho.

Conectar ao USB nativo

Como o build do OpenThread RCP permite o uso do ACM CDC nativo do USB como transporte serial, é necessário usar a porta nRF USB na placa nRF52840 para se comunicar com o host do RCP (máquina Linux).

Remova a extremidade micro USB do cabo USB da porta de depuração da placa nRF52840 atualizada e conecte-o novamente à porta USB nRF micro USB ao lado do botão REDEFINIR. Defina o interruptor da fonte de energia nRF como USB.

Iniciar o daemon do OpenThread

No design do RCP, use o Daemon do OpenThread para se comunicar e gerenciar o dispositivo Thread. Inicie ot-daemon com a sinalização detalhada -v para que você possa ver a saída do registro e confirmar se ela está em execução:

$ cd ~/src/openthread
$ sudo ./build/posix/src/posix/ot-daemon -v \
    'spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=115200'

Quando bem-sucedido, ot-daemon no modo detalhado gera uma saída semelhante a esta:

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

Deixe essa janela de terminal aberta para que os registros de ot-daemon possam ser visualizados.

Use o ot-ctl para se comunicar com o nó do RCP. ot-ctl usa a mesma CLI que o app da CLI do OpenThread. Portanto, você pode controlar os nós ot-daemon da mesma forma que os outros dispositivos Thread simulados.

Em uma segunda janela do terminal, inicie ot-ctl:

$ sudo ./build/posix/src/posix/ot-ctl
>

Verifique o state do nó 2 (o nó do RCP) que você começou com ot-daemon:

> state
disabled
Done

5. Configurar os FTDs

Os outros dois nós de linha de execução usados neste codelab são dispositivos de linha de execução completos (FTDs) no design padrão de system on chip (SoC). Em uma configuração de produção, é possível usar o wpantund, um driver de interface de rede de nível de produção, para controlar instâncias NCP do OpenThread, mas neste codelab vamos usar ot-ctl, a CLI do OpenThread.

Um dispositivo funciona como o Comissário para autenticar e comissionar dispositivos com segurança nessa rede. O outro dispositivo funciona como um Joiner que o comissário pode autenticar na rede Thread.

Criar e atualizar

Crie o exemplo FTD do OpenThread para a plataforma nRF52840, com os papéis " Commissioner" e "Joiner" ativados:

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

Navegue até o diretório com o binário da CLI do dispositivo de linha de execução completa (FTD) do OpenThread e converta-o para o formato hexadecimal:

$ cd ~/src/ot-nrf528xx/build/bin
$ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex

Conecte o cabo USB à porta micro USB, ao lado do pino de alimentação externo na placa nRF52840, e conecte-o à máquina Linux. Se o RCP ainda estiver conectado à máquina Linux, essa nova placa aparecerá como porta serial /dev/ttyACM1 (todas as placas nRF52840 usam ttyACM como identificador de porta serial).

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

Como antes, anote o número de série da placa nRF52840 que está sendo usada para o FTD:

Navegue até o local das ferramentas de linha de comando nRFx e atualize o arquivo hexadecimal FTD da OpenThread CLI na placa nRF52840, usando o número de série da placa:

$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
       ~/src/ot-nrf528xx/build/bin/ot-cli-ftd.hex --reset

Rotule o conselho como "Comissário".

Conectar ao USB nativo

Como o build FTD do OpenThread permite o uso do ACM CDC nativo do USB como transporte serial, é necessário usar a porta nRF USB na placa nRF52840 para se comunicar com o host do RCP (máquina Linux).

Verificar build

Verifique se o build foi bem-sucedido acessando a CLI do OpenThread usando o GNU Screen em uma janela de terminal. As placas nRF52840 usam uma taxa de Baud de 115200.

$ screen /dev/ttyACM1 115200

Na nova janela, pressione Return no teclado algumas vezes para abrir a solicitação > da CLI do OpenThread. Acesse a interface IPv6 e verifique os endereços:

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

Use Ctrl+a →

d para se desconectar da tela FTD Commissioner CLI e retornar ao terminal Linux para que a próxima placa possa ser atualizada. Para retornar à CLI a qualquer momento, use screen -r na linha de comando. Para conferir uma lista de telas disponíveis, use screen -ls:

$ screen -ls
There is a screen on:
        74182.ttys000.mylinuxmachine        (Detached)
1 Socket in /tmp/uscreens/S-username.

Configurar o Joiner de FTD

Repita o processo acima para atualizar a terceira placa nRF52840, usando o build ot-cli-ftd.hex já existente. Quando terminar, reconecte a placa ao PC usando a porta USB nRF e defina a chave da fonte de energia nRF como VDD.

Se os outros dois nós estiverem anexados à máquina Linux quando essa terceira placa for conectada, ela vai aparecer como a porta serial /dev/ttyACM2:

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

Marque a placa como "Joiner".

Ao fazer a verificação usando o Screen, em vez de criar uma nova instância de Screen na linha de comando, anexe de novo à atual e crie uma nova janela dentro dela (que você usou para o FTD Commissioner):

$ screen -r

Crie a nova janela dentro da tela com Ctrl+a → c.

Um novo prompt de linha de comando será exibido. Acesse a CLI do OpenThread para o Joiner do FTD:

$ screen /dev/ttyACM2 115200

Nessa nova janela, pressione Return no teclado algumas vezes para abrir a solicitação > da CLI do OpenThread. Acesse a interface IPv6 e verifique os endereços:

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

Agora que a CLI do FTD Joiner está na mesma instância de Screen que o FTD Commissioner, é possível alternar entre eles usando Ctrl+a → n.

Use Ctrl+a →

d a qualquer momento para sair da tela.

6. Configuração da janela do terminal

A partir de agora, você vai alternar entre dispositivos Thread com frequência, então confira se todos eles estão ativos e de fácil acesso. Até agora, usamos o Screen para acessar os dois FTDs, e essa ferramenta também permite a divisão da tela na mesma janela do terminal. Use esse recurso para ver como um nó reage aos comandos emitidos em outro.

O ideal é ter quatro janelas disponíveis:

Serviço / registros do ot-daemon
Combinador de RCP via ot-ctl
FTD Commissioner (link em inglês) pela CLI OpenThread
FTD Joiner via CLI OpenThread

Se você quiser usar sua própria ferramenta ou configuração de porta serial / terminal, pule para a próxima etapa. Configure as janelas de terminal para todos os dispositivos da maneira que funcionar melhor para você.

Como usar a tela

Para facilitar o uso, inicie apenas uma sessão na tela. Você já deve ter um quando configurar os dois FTDs.

Todos os comandos na tela começam com Ctrl+a.

Comandos básicos da tela:

Reanexar à sessão da tela (usando a linha de comando).	`screen -r`
Sair da sessão de tela	Ctrl + A → `d`
Criar nova janela na sessão "Tela"	Ctrl + A → `c`
Alternar entre janelas na mesma sessão de tela	Ctrl+a → `n` (avançar)Ctrl+a → `p` (voltar)
Encerrar a janela atual na sessão "Tela"	Ctrl + A → `k`

Tela dividida

Com o Screen, é possível dividir o terminal em várias janelas:

Os comandos em screen são acessados usando Ctrl+a. Todos os comandos devem começar com esta combinação de teclas de acesso.

Se você estiver seguindo o codelab exatamente, terá duas janelas (FTD Commissioner, FTD Joiner) na mesma instância de tela. Para dividir a tela entre os dois, primeiro insira sua sessão de tela atual:

$ screen -r

Você deve estar em um dos dispositivos FTD. Siga estas etapas na tela:

Ctrl+a → S para dividir a janela horizontalmente
Ctrl+a → Tab para mover o cursor para a nova janela em branco.
Ctrl+a → n para alternar essa nova janela para a próxima.
Se ele for igual à janela superior, pressione Ctrl+a → n novamente para visualizar o outro dispositivo FTD.

Agora os dois estão visíveis. Alterne entre elas usando Ctrl+a → Tab. Recomendamos renomear cada janela com Ctrl+a → A para evitar confusão.

Uso avançado

Para dividir ainda mais a tela em quadrantes e conferir os registros de ot-daemon e o ot-ctl do Joiner do RCP, esses serviços precisam ser iniciados nessa mesma instância da tela. Para fazer isso, pare ot-daemon, saia de ot-ctl e reinicie-os em novas janelas de tela (Ctrl+a → c).

Essa configuração não é necessária e é um exercício para o usuário.

Divida e navegue entre janelas com os seguintes comandos:

Criar nova janela	Ctrl + A → `c`
Dividir janela verticalmente	Ctrl + A →
Dividir janela horizontalmente	Ctrl + A → `S`
Ir para a próxima janela exibida	Ctrl + A → `Tab`
Mudar a janela exibida para frente ou para trás	Ctrl+a → `n` ou `p`
Renomear a janela atual	Ctrl + A → `A`

Saia da tela a qualquer momento pressionando Ctrl+a → d e anexe novamente com screen -r na linha de comando.

Para mais informações sobre o Screen, consulte a referência rápida da tela do GNU.

7. Criar a rede Thread

Agora que você configurou todas as janelas e telas de terminal, vamos criar nossa rede Thread. No FTD Commissioner, crie um novo conjunto de dados operacional e confirme-o como o ativo. O conjunto de dados operacional é a configuração da rede Thread que você está criando.

## 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

Anote a chave de rede 1234c0de7ab51234c0de7ab51234c0de, porque ela será usada mais tarde.

Confirme este conjunto de dados como o ativo:

> dataset commit active
Done

Abra a interface IPv6:

> ifconfig up
Done

Inicie a operação do protocolo Thread:

> thread start
Done

Após alguns instantes, verifique o estado do dispositivo. Ele deve ser o líder. Receba também o RLOC16 para referência futura.

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

> state
leader
Done
> rloc16
0c00
Done

Verifique os endereços IPv6 do 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)

O "codelab" agora fica visível quando é feita a leitura de outros dispositivos Thread.

Em ot-ctl no RCP Joiner:

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

> scan
| PAN  | MAC Address      | Ch | dBm | LQI |
+------+------------------+----+-----+-----+
| c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |

Na CLI do OpenThread no FTD Joiner:

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

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

Se o "codelab" não aparecer na lista, tente procurar novamente.

8. Adicionar o Joiner do RCP

O comissionamento do Thread não está ativo na rede, o que significa que precisaremos adicionar o Joiner RCP à rede Thread que acabamos de criar usando um processo de comissionamento fora de banda.

No FTD Commissioner, registramos a chave de rede, por exemplo, 1234c0de7ab51234c0de7ab51234c0de. Se você precisar pesquisar a chave de rede novamente, execute o seguinte comando no FTD Commissioner:

## FTD Commissioner ##

> dataset networkkey
1234c0de7ab51234c0de7ab51234c0de
Done

Em seguida, no RCP Joiner, defina a chave de rede ativa do conjunto de dados como a chave de rede do FTD Commissioner:

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

> dataset networkkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

Verifique se o conjunto de dados está definido corretamente.

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

> dataset
Network Key: 1234c0de7ab51234c0de7ab51234c0de

Abrir o Thread para que o Joiner do RCP entre no "codelab". em uma rede VPC. Aguarde alguns segundos, verifique o estado, RLOC16 e os endereços 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

Anote o endereço IPv6 da rede mesh-local (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f aqui). Você vai usá-lo mais tarde.

De volta ao FTD Commissioner, verifique as tabelas do roteador e das filhas para confirmar que os dois dispositivos fazem parte da mesma rede. Use o RLOC16 para identificar o Joiner do 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

Dê um ping no endereço local da malha do Joiner do RCP (o endereço local da rede mesh recebido da saída ipaddr do Joiner do RCP) para verificar a conectividade:

## 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

Agora temos uma rede Thread com dois nós, ilustrado por este diagrama de topologia:

Diagramas de topologia

À medida que você avançar no codelab, mostraremos um novo diagrama de topologia de linha de execução sempre que o estado da rede mudar. Os papéis de nó são indicados da seguinte maneira:

Os roteadores são sempre pentágonos e os dispositivos finais são sempre círculos. Os números em cada nó representam o ID do roteador ou o ID filho mostrado na saída da CLI, dependendo do papel e do estado atuais de cada nó naquele momento.

9. Comissionamento do Joiner de FTD

Agora, vamos adicionar o terceiro dispositivo Thread ao "codelab". em uma rede VPC. Desta vez, usaremos o processo de comissionamento em banda mais seguro e permitiremos apenas a participação do Joiner do FTD.

No FTD Joiner, receba o eui64 para que o Comissário de FTD possa identificá-lo:

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

> eui64
2f57d222545271f1
Done

Em FTD Commissioner, inicie o comissário e especifique o eui64 do dispositivo que pode ser usado, além da credencial do Joiner, por exemplo, J01NME. A credencial do Joiner é uma string específica do dispositivo com todos os caracteres alfanuméricos maiúsculos (0-9 e A-Y, excluindo I, O, Q e Z para facilitar a leitura), com 6 a 32 caracteres.

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

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

Mude para o FTD Joiner. Inicie a função de Joiner com a credencial de Joiner que você acabou de configurar no FTD Commissioner:

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

> ifconfig up
Done
> joiner start J01NME
Done

Em cerca de um minuto, você receberá a confirmação de uma autenticação bem-sucedida:

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

>
Join success

Abrir o Thread para que o Joiner FTD participe do "codelab". e verifique imediatamente o estado e a RLOC16:

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

> thread start
Done
> state
child
Done
> rloc16
0c02
Done

Verifique os endereços IPv6 do dispositivo. Observe que não há ALOC. Isso ocorre porque esse dispositivo não é o líder nem tem um papel específico do Anycast que requer um 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)

Mude imediatamente para FTD Commissioner e verifique as tabelas do roteador e das filhas para confirmar se há três dispositivos no "codelab". rede:

## 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

Com base no RLOC16, o Joiner FTD foi anexado à rede como um Dispositivo final (filho). Confira nossa topologia atualizada:

10. Linha de execução em ação

Os dispositivos Thread deste codelab são um tipo específico de dispositivo de linha de execução completa (FTD, na sigla em inglês) chamado de Dispositivo final qualificado para roteador (REED, na sigla em inglês). Isso significa que eles podem funcionar como um roteador ou um dispositivo final e podem se promover de um dispositivo final para um roteador.

O Thread oferece suporte a até 32 roteadores, mas tenta manter o número entre 16 e 23. Se um REED é anexado como um Dispositivo final (filho) e o número de Roteadores for menor do que 16, após um período aleatório dentro de dois minutos, ele se promoverá automaticamente a um Roteador.

Se você tiver dois filhos na sua rede Thread após adicionar o FTD Joiner, aguarde pelo menos dois minutos e verifique novamente as tabelas do roteador e do filho no 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

O FTD Joiner (MAC estendido = e6cdd2d93249a243) foi promovido a roteador. O RLOC16 é diferente (b800 em vez de 0c02). Isso ocorre porque o RLOC16 é baseado no ID do roteador e no ID filho de um dispositivo. Quando ele passa do dispositivo final para o roteador, os valores de ID do roteador e ID filho mudam, assim como o RLOC16.

Confirme o novo estado e o RLOC16 no FTD Joiner:

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

> state
router
Done
> rloc16
b800
Done

Fazer downgrade do Joiner do FTD

Você pode testar esse comportamento fazendo downgrade manual do FTD Joiner de um roteador para um dispositivo final. Mude o estado para filho e verifique o RLOC16:

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

> state child
Done
> rloc16
0c03
Done

De volta ao FTD Commissioner, o FTD Joiner será exibido na tabela filha (ID = 3). Pode até estar em ambos durante as transições:

## 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

Após algum tempo, ele voltará para um roteador com um RLOC de b800.

Remover o líder

O líder é autoeleito entre todos os roteadores de linha de execução. Isso significa que, se o líder atual for removido da rede Thread, um dos outros roteadores se tornará o novo líder.

No FTD Commissioner, encerre o Thread para removê-lo da rede:

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

> thread stop
Done
> ifconfig down
Done

Em dois minutos, o FTD Joiner se torna o novo líder de linha de execução. Verifique o estado e os endereços IPv6 do Joiner do FTD:

## 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

Verifique a tabela filha. Observe que há um novo RLOC16. Este é o Joiner do RCP, conforme indicado pelo ID e o MAC estendido. Para manter a rede Thread unida, ela trocou os roteadores pais do FTD Commissioner para o FTD Joiner. Isso resulta em um novo RLOC16 para o Joiner do RCP (porque o ID do roteador mudou de 3 para 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

Talvez seja necessário aguardar alguns minutos para que o Joiner do RCP seja anexado ao Joiner do FTD como um filho. Verifique o estado e o RLOC16 para confirmar se:

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

> state
child
> rloc16
b801

Reanexe o Comissário de FTD

Uma rede Thread com dois nós não é muito divertida. Vamos colocar o FTD Commissioner de novo on-line.

No FTD Commissioner, reinicie a linha de execução:

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

> ifconfig up
Done
> thread start
Done

Em dois minutos, ele é automaticamente reanexado ao "codelab". como um dispositivo final e depois se promove a roteador.

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

> state
router
Done

Verifique as tabelas do roteador e do filho no FTD Joiner para conferir:

## 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

Nossa rede Thread consiste novamente em três nós.

11. Solução de problemas

Gerenciar uma rede Thread com vários dispositivos em diferentes terminais ou janelas de tela pode ser complicado. Use estas dicas para "redefinir" o estado da rede ou do espaço de trabalho em caso de problemas.

Screen

Se você se perder na configuração (muitas janelas ou telas na tela demais), continue excluindo as janelas usando Ctrl+a → k até que não haja nenhuma e screen -ls na linha de comando gere No Sockets found. Em seguida, recrie as janelas de tela para cada dispositivo. Os estados do dispositivo são mantidos mesmo quando a tela é eliminada.

Nós da linha de execução

Se a topologia de rede Thread não for a descrita neste codelab ou os nós se desconectarem por algum motivo (talvez porque a máquina Linux que os alimenta tenha caído), é melhor desativar o Thread, limpar as credenciais da rede e começar de novo na etapa Criar a rede do Thread.

Para redefinir os FTDs:

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

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

O RCP pode ser redefinido da mesma maneira usando ot-ctl:

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

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

12. Como usar multicast

O multicast é usado para comunicar informações a um grupo de dispositivos de uma só vez. Em uma rede Thread, endereços específicos são reservados para uso multicast com diferentes grupos de dispositivos, dependendo do escopo.

Endereço IPv6	Escopo	Entregue a
`ff02::1`	Link-local	Todos os FTDs e MEDs
`ff02::2`	Link-local	Todos os FTDs e roteadores de borda
`ff03::1`	Malha local	Todos os FTDs e MEDs
`ff03::2`	Malha local	Todos os FTDs e roteadores de borda

Como não estamos usando um roteador de borda neste codelab, vamos nos concentrar nos dois endereços multicast FTD e MED.

Link-local

O escopo link-local abrange todas as interfaces Thread acessíveis por uma única transmissão de rádio ou um único "salto". A topologia de rede determina quais dispositivos respondem a um ping no endereço multicast ff02::1.

Dê um ping em ff02::1 pelo Comissário 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

Há outros dois dispositivos na rede (FTD Joiner e RCP Joiner), mas o FTD Commissioner recebeu apenas uma resposta do endereço link-local (LLA) do FTD Joiner. Isso significa que o FTD Joiner é o único dispositivo que o FTD Commissioner pode alcançar com um único salto.

Agora dê um ping em ff02::1 no Combinador 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

Duas respostas! Ao verificar os endereços IPv6 dos outros dispositivos, podemos ver que o primeiro (terminando em 4b1d) é o LLA do FTD Commissioner, e o segundo (terminando em 943b) é o LLA do RCP Joiner.

Isso significa que o FTD Joiner está diretamente conectado ao FTD Commissioner e ao RCP Joiner, o que confirma nossa topologia.

Malha local

O escopo Mesh-Local abrange todas as interfaces Thread acessíveis na mesma rede Thread. Vamos conferir as respostas a um ping no endereço multicast ff03::1.

Dê um ping em ff03::1 pelo Comissário 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

Desta vez, o FTD Commissioner recebeu duas respostas, uma do Localizador de roteamento do FTD Joiner (RLOC, terminando em b800) e outra do Mesh-Local EID do RCP Joiner (ML-EID, terminando em d55f). Isso ocorre porque o escopo mesh-local abrange toda a rede Thread. Não importa onde o dispositivo esteja na rede, ele será inscrito no endereço ff03::1.

Dê um ping em ff03::1 no Joiner do FTD para confirmar o mesmo comportamento:

## 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

Observe o tempo de resposta do Joiner do RCP nas duas saídas de ping. O Joiner do RCP levou muito mais tempo para alcançar o Comissário de FTD (68 ms) do que para alcançar o Comissário de FTD (23 ms). Isso ocorre porque é necessário fazer dois saltos para alcançar o Comissário de FTD, em comparação com um salto para o Joiner de FTD.

Você também pode ter notado que o ping de multicast mesh-local respondeu com o RLOC apenas para os dois FTDs, não para o Joiner do RCP. Isso ocorre porque os FTDs são roteadores dentro da rede, enquanto o RCP é um dispositivo final.

Verifique o estado do Joiner do RCP para confirmar:

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

> state
child

13. Enviar mensagens com UDP

Um dos serviços de aplicativo oferecidos pelo OpenThread é o protocolo de datagramas do usuário (UDP), um protocolo da camada de transporte. Um aplicativo criado no OpenThread pode usar a API UDP para transmitir mensagens entre nós em uma rede Thread ou para outros dispositivos em uma rede externa (como a Internet, se essa rede tiver um roteador de borda).

Os soquetes UDP são expostos pela CLI do OpenThread. Vamos usá-lo para transmitir mensagens entre os dois FTDs.

Consiga o endereço EID do Mesh-Local para o FTD Joiner. Estamos usando esse endereço porque ele pode ser acessado de qualquer lugar da rede 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

Inicie o UDP e vincule-o a um soquete para qualquer endereço IPv6:

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

> udp open
Done
> udp bind :: 1212

Alterne para o FTD Commissioner, inicie o UDP e conecte-se ao soquete configurado no FTD Joiner usando o ML-EID:

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

> udp open
Done
> udp connect fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd 1212
Done

A conexão UDP deve estar ativa entre os dois nós. Envie uma mensagem do Comissário de FTD:

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

> udp send hellothere
Done

No FTD Joiner, a mensagem UDP foi recebida.

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

> 10 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00 49153 hellothere

14. Parabéns!

Você criou uma rede Thread física.

Agora você sabe:

a diferença entre tipos de dispositivos Thread, papéis e escopos
como os dispositivos Thread gerenciam os estados dentro da rede.
como transmitir mensagens simples entre nós usando UDP

Próximas etapas

Com base neste codelab, faça os exercícios a seguir:

Atualize a placa do Joiner do FTD como um MTD usando o binário ot-cli-mtd e observe que ela nunca atualiza a si mesma para um roteador nem tenta se tornar líder.
Adicione mais dispositivos (tente usar uma plataforma diferente) à rede e esboce a topologia usando tabelas filhas e de roteadores, além de pings nos endereços multicast
Usar pyspinel para controlar o NCP
Converta o NCP em um roteador de borda usando o roteador de borda OpenThread (em inglês) e conecte a rede Thread à Internet

Leitura adicional

Acesse openthread.io e GitHub (links em inglês) para ver uma variedade de recursos do OpenThread, incluindo:

Plataformas compatíveis: descubra todas as plataformas compatíveis com o OpenThread
Build OpenThread: mais detalhes sobre a criação e a configuração do OpenThread
Thread Primer: abrange todos os conceitos do Thread apresentados neste codelab.

Referência: