Excerpt | |
---|---|
Prerequisites
|
...
|
...
Setting up |
...
the Thread NetworkForming |
...
a Network |
...
To form a network, you must start by determining the border router’s IP address, this could be done by running an arp-scan command and grepping for MMB’s identifier.
Direct your browser to that address to access the OpenThread Border Router landing page. |
...
Select ‘Form’ on the left side of the page to get to the Form Network |
...
menu where you can configure most |
...
of the network parameters. Adjust the parameters to your choosing, set up and |
...
make note of |
...
When you are satisfied with the network settings click ‘FORM’ at the bottom of the screen.
...
You will be prompted with a Dialog to confirm your settings, click ‘OK’
...
You will then see a dialog confirming the successful formation of the network.
...
Commissioning a Device to the Thread Network
Establish an SSH connection to your Enterprise OTBR
...
your passphrase as this will be your Border Agent passphrase. (Note: 8 digits passphrase preferred) Click the “FORM” button at the bottom of the window when done configuring your network parameters, you will then be prompted to confirm your choice, an operation success message will pop up upon network formation. Connecting a Thread End Device to the networkEstablish an SSH ConnectionTo join a new device, in a new terminal ssh into the gateway by running the following command where address is the gateway’s IP address fetched previously (i.e mmb@192.168.1.101)
Detailed instructions about establishing a ssh connection with your gateway are provided on our Establishing an SSH connection to the Gateway page |
...
. |
Starting the Commissioning process on the Enterprise OTBR
...
Start the CommissionerOnce logged in, launch the OTBR command utility by running the following command
From here on you can type “help” for a full list of supported commands, you can also verify the value of the parameters previously set in the web GUI such as the network’s name, panID, masterkey and others.
Start the commissioner by running ot command
Allow devices to join by running ot command
|
What these commands do:
Start the commissioner
Add a joiner of ANY EUI64, with a timeout of 60 seconds, with the joiner password of “password”
You can change the timeout value to be longer if you feel it is necessary.
Commissioning an OpenThread Full Thread Device
...
NOTE: When selecting a joiner password, the password must contain only a combination of uppercase letters and numbers, but may not include the letters “I”, “O”, “Q”, “Z”. The password must be between 6 and 32 characters in length. Setup and Join an OpenThread CLI DeviceNote: This step assumes the user has a device running OpenThread’s Full Thread Device (ftd) CLI |
...
with the JOINER |
...
Code Block | ||
---|---|---|
make -f examples/Makefile-nrf52840 USB=1 BOOTLOADER=USB BORDER_AGENT=1 BORDER_ROUTER=1 COMMISSIONER=1 JOINER=1 UDP_PROXY=1 UDP_FORWARD=1 COAP=1 COAPS=1 DNS_CLIENT=1 LINK_RAW=1 compile time flag enabled. Establish a serial connection with the FTD device by running, in a separate terminal, the following command where XXXX is the port number assigned to the device upon connection (i.e ttyACM0)
Run the following commands to |
...
make sure all configurations are cleared.
Bring up > joiner start password |
There will be no response to the factoryreset or the reset command. Output should match the image below, with ‘12345678’ being the password used.
...
up the device by running
Enable the joiner role and provide the same passphrase set up in the commissioner Note: This command has to be run while the commissioner joiner command has not yet expired (you will get a “joiner remove” message on the commissioner side if that was the case).
The join process can take up to a minute |
...
, once done you should expect a message on your gateway (commissioner) to alert you that a new device has joined the network successfully.
Once the commissioner reports a successful device join, on your joiner device start thread by running
|
...
This process can take a few second, after which you can run “state”, the joiner will then report back its role in the network, the role is assigned to the device by the network based on the current topology and will be either a router or a child
|
If state returns ‘child’ or ‘router’, the device was successfully joined.
...
You can also fetch the device on your commissioner device by running Testing Thread Network ConnectivityOn-Mesh Pinging |
...
Run the following command on the Enterprise OTBR ssh session to obtain its |
...
on-mesh IPV6 address, note that if you are still running in the ot command utility you need to press Ctrl+C to exit that environment first.
|
and the output should look something like this:
Code Block | ||
---|---|---|
wpan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::7266:d7c6:b667:2c68/64 Scope:Link
inet6 addr: fd11:1111:1122:0:167e:20d5:ce:2d56/64 Scope:Global
inet6 addr: fe80::44e6:cb4e:6eee:cd25/64 Scope:Link
we are looking for an inet6 address that starts with the prefix assigned to the commissioner when forming the network, in our case that is
|
The ‘inet6 addr’ we are interested in is the one which has an address inside our On-Mesh Prefix (fd11:22::) that we specified when we created the network in the ‘Setting up a Thread Network’ section above.
...
Code Block | |||
---|---|---|---|
From your joiner device, ping the commissioner on that address, the output should return immediately and look as follows
|
and the ping should return immediately with output that looks similar to this:
Off-Mesh Pinging |
...
Run the following command on the gateway to bring up radvd and allow on-mesh devices to ping off resources (i.e IPv6 LAN resources), this command will start router advertisements as necessary, and add the Off-Mesh Routes to the thread network.
If you don’t have LAN IPv6 support, it should output something similar to the following:
After this command is run, router advertisements will be broadcast by the Enterprise OTBR, giving your LAN devices IPv6 connectivity. You can confirm this by checking the IPv6 addresses associated with another device on your LAN |
...
Example, my developer machine now has an address from the prefix that matches the output from ipv6-radvd-dispatcher (fd11:2446:a285:cdb2:ec89:a088:3f76:bdf6
):
Code Block | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.50.222 netmask 255.255.255.0 broadcast 192.168.50.255
, running an
The thread end device and the developer machine on the LAN can now contact each other via the border router. Run the ping command on the thread end device to see it in action:
Congratulations, you are now running a Thread Border Router on the Enterprise OTBR. Pinging an |
...
IPv4 Resource Using NAT64The Enterprise OTBR is |
...
loaded with Tayga for NAT64 translations |
...
to allow communication between IPV6 and IPV4 resources. Tayga can be configured to meet network requirements by editing /etc/tayga.conf and /etc/default/tayga |
...
files. |
...
The Enterprise OTBR is |
...
configured to use the well known 6-to-4 prefix of “64:ff9b::/96” |
...
, this means that in order to ping an |
...
IPv4 resource from |
...
your thread end device, |
...
this prefix has to prepend that resource’s address. To ping the Google public DNS server of 8.8.8.8, issue the following command |
...
to the thread end device |
...
Code Block | ||
---|---|---|
|
which should return:
LimitationsThe 6-to-4 |
...
prefix does not allow NAT64 to operate inside the LAN on which it sits |
...
, thus to ping a LAN device, the “prefix” directive inside /etc/tayga.conf would have to be changed to something in the Unique Local Unicast range of fc00::/7. Confirm that you cannot ping a LAN device |
...
Converting your LAN device’s IPv4 address to the 4-in-6 format inside the well-known prefix and attempt to ping it, this should not return a response. Example: 192.168.0.2 becomes 64:ff9b::c0a8:0002 ( |
...
192 = 0xc0, 168 = 0xa8, … )
|
...
To remedy this, open /etc/tayga.conf and change the “prefix” directive to a prefix in fc00::/7. An example of a prefix in this range is fd11:2446:64::/96 which is included in the file at the time of this writing, so all that is required is to comment out the existing prefix and uncomment the provided one. |
...
Restart Tayga with the following command |
...
, run the ping command with the new prefix and it should return successfully
After Tayga restarts, |
...
you will be able to successfully ping the address from your end device.
|