please critique border router network setup script

[mjkuwp94]

Hello,  I have had to set up and troubleshoot my border router many times so I am trying to make a script to automate it and of course help me to not miss steps.  It seems to work on fresh start and for redoing the network as well.  The part I am least confident in is the addition of prefixes which I honestly struggle to understand. 
This script is just for the building of the Thread network on the otbr. I am totally doing away with any external joining or commissioning techniques as I consider those too advanced for a beginner.  This is just to get *something* functional.

#!/bin/sh
# 2021 04-12
# nordic pca10059 radio co-processor RCP built with this command and flashed with nRF Connect
# make -f examples/Makefile-nrf52840 USB=1 BOOTLOADER=USB DOT_THREAD_VERSION=1.2
#
sudo ot-ctl factoryreset

sleep 2
sudo ot-ctl thread stop
sudo ot-ctl ifconfig down
sudo ot-ctl dataset clear
sudo ot-ctl dataset init new
sudo ot-ctl dataset panid 0xaa55
sudo ot-ctl dataset extpanid 11112222deadbeef
sudo ot-ctl dataset networkname net2
sudo ot-ctl dataset channel 17
sudo ot-ctl dataset masterkey 00112233445566778899aabbccddeeff
result=$(/home/pi/ot-br-posix/build/otbr/tools/pskc MARK25 11112222deadbeef net2)
echo $result
sudo ot-ctl dataset pskc $result
sudo ot-ctl dataset commit active
sudo ot-ctl prefix add 2001::/64 paros
sudo ot-ctl ifconfig up
sudo ot-ctl thread start
sudo ot-ctl netdata register
sudo ot-ctl state
sudo ot-ctl pskc
sleep 5
sudo ot-ctl state
sudo ot-ctl netdata show

output is:  (my public ipv6 is covered with ####:)

Done
Done
Done
Done
Done
Done
Done
Done
Done
a04509d13b9bee2ce871ceefbb0de3d8
Done
Done
Done
Done
Done
Done
detached
Done
a04509d13b9bee2ce871ceefbb0de3d8
Done
leader
Done
Prefixes:
2001:0:0:0::/64 paros med b400
Routes:
2600:####:####:####::/64 s med b400
fd4c:4859:a9c5:0::/64 s med b400
Services:
44970 5d c000 s b400
44970 01 7104b000000e10 s b400
Done

I feel like a nominal setup is almost in reach.


I did the above commands and then rebooted the otbr.

after rebooting I ssh in and perform these commands manually
sudo ot-ctl prefix add 2001::/64 paros
sudo ot-ctl netdata register

thing I am not clear on is why a non-meaningful prefix such as 2001::/64 is required to be added manually after booting for function.  If this prefix doesn't mean anything why  couldn't it be part of the code so that one wouldn't have to figure out how to add this after a reboot?

or, likely I have misunderstood something and this prefix is supposed to be my local router's 64- bit prefix.  Problem is, when I have tried substituting my own router's prefix things get worse instead of better.  I hope I am very close to the solution.

thanks!

[Jonathan Hui]

Responses below:

On Mon, Apr 12, 2021 at 7:55 AM mjkuwp94 <mjk...@gmail.com> wrote:

Hello,  I have had to set up and troubleshoot my border router many times so I am trying to make a script to automate it and of course help me to not miss steps.  It seems to work on fresh start and for redoing the network as well.  The part I am least confident in is the addition of prefixes which I honestly struggle to understand. 
This script is just for the building of the Thread network on the otbr. I am totally doing away with any external joining or commissioning techniques as I consider those too advanced for a beginner.  This is just to get *something* functional.

#!/bin/sh
# 2021 04-12
# nordic pca10059 radio co-processor RCP built with this command and flashed with nRF Connect
# make -f examples/Makefile-nrf52840 USB=1 BOOTLOADER=USB DOT_THREAD_VERSION=1.2
#
sudo ot-ctl factoryreset

sleep 2
sudo ot-ctl thread stop
sudo ot-ctl ifconfig down
sudo ot-ctl dataset clear
sudo ot-ctl dataset init new
sudo ot-ctl dataset panid 0xaa55
sudo ot-ctl dataset extpanid 11112222deadbeef
sudo ot-ctl dataset networkname net2
sudo ot-ctl dataset channel 17
sudo ot-ctl dataset masterkey 00112233445566778899aabbccddeeff

If possible, I would recommend using the randomly chosen values provided by dataset init new when forming a new network.

 

result=$(/home/pi/ot-br-posix/build/otbr/tools/pskc MARK25 11112222deadbeef net2)

For computing the pskc, you can also use the pskc OpenThread CLI command.

 

echo $result
sudo ot-ctl dataset pskc $result
sudo ot-ctl dataset commit active
sudo ot-ctl prefix add 2001::/64 paros

If you just want NAT64 to work with well-known prefix, you can replace this command with:

route add 64:ff9b::/96 s

The most important part of the prefix add command is the 'r' flag, which indicates "default route". As mentioned above, if all you want is to demonstrate NAT64 with the well-known prefix, then you can replace it with an explicit route command:

route add 64:ff9b::/96 s

 

or, likely I have misunderstood something and this prefix is supposed to be my local router's 64- bit prefix.  Problem is, when I have tried substituting my own router's prefix things get worse instead of better.  I hope I am very close to the solution.

IPv6 prefixes should be unique to a given IPv6 link. You should not attempt to configure an IPv6 prefix that was assigned to other links (including wlan0 or eth0).

--
Jonathan Hui

[mjkuwp94]

thanks!

The reason I was explicitly setting all of the data is because I could not get the ThreadGroup Android app to work reliably as a Commissioner and then later could not get the otbr web ui commissioner to start.  I think the web ui Commission tab is still broken or else I fail to understand how it works.  It will be best if I use the command line commissioner and Device's join function to add the Devices.


question: would a person need to install and configure radvd  to have other PCs on the LAN reach the Thread network with an assigned prefix?  or will radvd conflict with something in otbr.?

this is the netdata I have now after adding two prefixes.  I am trying to mimic what Kibra offered which I think is a prefix for the LAN advertised with radvd.  My devices currently can ping the public and each other and my local/other PC but I cannot ping the Thread network from the PC and I suppose this is because the prefix is not advertised.

the fd0x:6d27:86f7:0::/64 is just a link local that I 'made up' and added with the ot-ctl commands

Prefixes:

fd0c:6d27:86f7:0::/64 paos med 9c00

2001:0:0:0::/64 paros med 9c00

Routes:

2600:6c44:597f:cfcd::/64 s med 9c00

fd4c:4859:a9c5:0::/64 s med 9c00

Services:

44970 5d c000 s 9c00

44970 01 cd04b000000e10 s 9c00

Done

by the way, I think it would be really helpful to have a cookbook/recipe book for adding prefixes (and routes?) based on different goals or even just 1 standard example that can communicate with the LAN and the internet via ipv6.  In searching for my solution I have found that the question I am asking has come up many times and been answered many times but the knowledge gap for me is too big to bridge even with this information.  I think it is a common source of confusion for people new to Thread and who are very likely new to ipv6 and even ip networks in general.

[Jonathan Hui]

On Tue, Apr 13, 2021 at 6:40 AM mjkuwp94 <mjk...@gmail.com> wrote:

thanks!

The reason I was explicitly setting all of the data is because I could not get the ThreadGroup Android app to work reliably as a Commissioner and then later could not get the otbr web ui commissioner to start.  I think the web ui Commission tab is still broken or else I fail to understand how it works.  It will be best if I use the command line commissioner and Device's join function to add the Devices.

A proposed fix for the Commissioner Web UI tab is at openthread/ot-br-posix#781

 

question: would a person need to install and configure radvd  to have other PCs on the LAN reach the Thread network with an assigned prefix?  or will radvd conflict with something in otbr.?

If you used the INFRA_IF_NAME option when invoking ./script/setup, you should not need to use radvd to have devices on the infrastructure link route to your Thread network.

 

this is the netdata I have now after adding two prefixes.  I am trying to mimic what Kibra offered which I think is a prefix for the LAN advertised with radvd.  My devices currently can ping the public and each other and my local/other PC but I cannot ping the Thread network from the PC and I suppose this is because the prefix is not advertised.

the fd0x:6d27:86f7:0::/64 is just a link local that I 'made up' and added with the ot-ctl commands

The fd00:: prefix is the unique local prefix, not link-local prefix (which is fe80::/10).

Prefixes:

fd0c:6d27:86f7:0::/64 paos med 9c00

2001:0:0:0::/64 paros med 9c00

Routes:

2600:6c44:597f:cfcd::/64 s med 9c00

fd4c:4859:a9c5:0::/64 s med 9c00

Services:

44970 5d c000 s 9c00

44970 01 cd04b000000e10 s 9c00

Done

by the way, I think it would be really helpful to have a cookbook/recipe book for adding prefixes (and routes?) based on different goals or even just 1 standard example that can communicate with the LAN and the internet via ipv6.  In searching for my solution I have found that the question I am asking has come up many times and been answered many times but the knowledge gap for me is too big to bridge even with this information.  I think it is a common source of confusion for people new to Thread and who are very likely new to ipv6 and even ip networks in general.

The INFRA_IF_NAME feature is relatively recent. If you are using that feature, then other devices on the infrastructure network should be able to reach the Thread network.

--

Jonathan Hui

[mjkuwp94]

"The fd00:: prefix is the unique local prefix, not link-local prefix (which is fe80::/10)."

oh, yes shoot. I  know that and mis-wrote that when I made my message, sorry about that.  I think Unique Local is the proper term for this group that is not global but is routable.  link-local cannot be routed and will only reach the neighbor.

I did build the otbr very recently and useed the  INFRA_IF_NAME  ,so I will not use radvd and will continue working on the prefix and route configuration.