We need a document to describe how to perform Thread Commissioning with OpenThread and OpenThread Border Router.

Content may cover these steps:

• Build and program NCP device
• Build an OpenThread Border Router with a RPi 3B
• Form a Thread network with OpenThread Border Router
• Install ThreadGroup Commissioning App
• Scan and select Border Router through Commissioning App
• Build and program a Joiner device
• Commission a Joiner device into the existing Thread network
• Ping or communicate with a host located in Internet

Jun 19 07:44:41 raspberrypi otWeb[32554]: connection is NULL.

Quick fix revert to commit 253cba0

This occurs with the main readme.md file.

Specifically the large block diagram, the link points to:
(note: I have to mangle the LINK otherwise the ISSUE tracker treats this as a real link)
-> OTBR Architecture ->
HTTPS://gist.githubusercontent.com/Vyrastas/0489e2c081c0444c2462dcee54962cb7/raw/100a8a08f1e9103672017f0f05eac6f85cb8e31a/otbr-arch-borderagent_2x.png

Image links currently links point to an incomprehensible location sort of like: http://blahblah...googleusercontent...blabblah/somename/commitid/blahblah

They should instead be (a) part of the overall archive, and (b) be relative links not absolute links to files elsewhere (ie: Self contained)

Just an FYI, if you're interested in the status of, "Key Reinstallation Attacks" aka KRACK for WPA2, on Raspbian, see this thread.

I used the latest code, but the script always failed and show the following log:
...
Connection 'BorderRouter-AP' (9e68a65d-ba48-437b-9630-90d75916baba) successfully added.
...
Connection 'BorderRouter-Eth' (e20bda30-0d90-442d-abaf-70eb6d4b4316) successfully added.
Error: Timeout 90 sec expired.

Opening this issue as part of the Wiki deprecation.

Currently, PSKc passphrases cannot be set via the CLI. To set a PSKc passphrase for commissioning, you must use the "Form" Web UI when creating a new Thread network using OTBR.

This will eventually be noted in a Thread Commissioning guide using the OTBR Web UI, tracked in #62 . At that time we can close, or leave it open if this is functionality that should eventually be available via the CLI.

Some embedded platforms already have a WEB service running on Port 80...

The beagle bone is one of them, it would be nice if the border router web interface
could be easily configured, or fail over to some other port, for example 8080?

steps to reproduce:

1. Start/Form a network.
2. Exit/halt the border router.
3. Restart the border router.
4. On android app - no adverts appear.
5. form a network, you seem to need to change something so change the panid, and networkname
6. Now the border router is advertized

Expected operation: When BR restarts, the BR should automatically start the mDNS advertising.

Also -(related) from a usability point of view, it would be nice if the commissioning app could direct the user to a web commissioning app if no-network exists on the BR.. otherwise it is dead, and you (the victim/customer/neophite/non-technical person don't know what is going on.
or maybe the BR could avertise something on mDNS that would get the user/victim to the randomly assigned DHCP address of the border router.

When I try to deploy board borderrouter on ARTIK5 which running Fedora，Is it possible to deploy on ARTIK5?

The LIBCOAP package seems to not play nicely when your shell=dash (the default on some debian platforms) specifically it cannot find the compiler.

The solution is to document that the developer must switch the system shell to bash

Not sure where this goes - but in the total system level documentation these things are missing:

a) How to use the Thread Commissioning app to configure the border router it self.

b) How to "de-commission" the Border Router - sort of "factory reset" back to not-commissioned state.

c) starting with the commissioned border router, but it is a singleton. Example should show how to configure a CLI device to act as joiner, and then commission that CLI device with the Commissioning app.

As a general outline:

Step 1 - Create a network using the CLI example.
Step 2 - Using the BR-WEB-SERVICE - Join that network.
Step 3 - Use the Openthread Commissioning Application to find the border router.
Step 4 - Select and tap on the OpenThread Border Router
Step 5 - The Commissioning App requests a pass phrase

What needs to be documented is: Where/how is this pass phrase created.

Same would apply to a CLI device that you want to "join/commission"

Opening this issue as part of the Wiki deprecation.

Currently, the public release of the Thread Commissioning App cannot be used for testing with OTBR.

This will eventually be noted in a Thread Commissioning guide using the OTBR Web UI, tracked in #62 . At that time we can close, or leave it open until we get the public release of the Thread Commissioning App updated.

Update3: For those who find this via google searches..

Look carefully at your RPi - the difference between the Pi2 vrs Pi3 is subtle, and the numbering is small and sometimes blurry. Raspberry PI v2 is an armv6 platform, not an armv7 - default build tools are currently not included for armv6, only armv7.

update1 a bit more context, this fails in the libcoap step)

a) Update 2 (adding items a,b,c,...) per the Wiki and instructions, this was validated against Raspberry Pi 3B (running recent Raspbian Jessie Lite)

b) I have that image, the SHA1SUM (note this not the md5sum) I have match the web site.

dad2ba8a228f14e64af7d80e1fd2503facb70c61 *2017-04-10-raspbian-jessie-lite.img
c24a4c7dd1a5957f303193fee712d0d2c0c6372d *2017-04-10-raspbian-jessie-lite.zip

Note that the web site shows the "sha1" of the ZIP not the IMG file.

c) If you boot that image, and execute: 'uname -m' you get: "armv6l"

in the end that output is used to select the binary directory in the thirdparty/nltools binaries are kept.

Specifically, the host tripplet becomes: armv6l-unknown-linux-gnueabihf

However, the prebuilt has armv7 only.

d) Per this post, the RPI Jessie is purposely built this way.

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=147887

Conclusion, you are testing with a different version of the RaspberryPi JessieLite?

If so can you give the details?

+ ./bootstrap
patching file repo/Makefile.am
patching file repo/libcoap-1.map
patching file repo/libcoap-1.sym
patching file repo/src/net.c
patching file repo/include/coap/bits.h
patching file repo/src/resource.c

[HINT] You can run 'autogen.sh --clean' to remove all generated files by the autotools.

Found 'autoconf'.
Found 'aclocal'.
Found 'pkg-config'.

Couldn't find 'libtool'!
Found 'libtoolize'.

  --->  Found all needed tools! That's fine.

Generating needed autotools files for libcoap by running autoreconf ...
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force ${ACLOCAL_FLAGS} -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:31: installing './ar-lib'
configure.ac:26: installing './compile'
configure.ac:37: installing './config.guess'
configure.ac:37: installing './config.sub'
configure.ac:18: installing './install-sh'
configure.ac:18: installing './missing'
Makefile.am: installing './INSTALL'
Makefile.am: installing './depcomp'
autoreconf: Leaving directory `.'

You can now run 'configure --help' to see possible configuration options.
Otherwise process the configure script to create the makefiles and generated helper files.

./third_party/nlbuild-autotools/repo/scripts/bootstrap: 180: ./third_party/nlbuild-autotools/repo/scripts/bootstrap: cannot open /home/pi/borderrouter/third_party/nlbuild-autotools/repo/tools/host/armv6l-unknown-linux-gnueabihf/bin/libtoolize: No such file
chmod: cannot access ‘/tmp/tmp.bootstrapIQOsmB/libtoolize’: No such file or directory
Can't locate object method "good_version" via package "Autom4te::C4che" at /usr/bin/autom4te line 1002.
aclocal: error: echo failed with exit status: 25

Originally reported by Stuart Longland from openthread-users.

Hello,
I would like to use border router with KW41Z platform in my project. I followed the installation guide, and everything is running as expected. I can configure and form network etc.

When I try to join the network by device with OT cli firmware using external commissioner (with Thread 1.1 Commissioning App), the process always fails. Client data transmission fails with NoAck error. Client is not able to start handshake with commissioner. CLI device and mobile app logs are attached.
app_log.txt
cli_log_info.log

I've tried OTBR on two different platforms (Raspberry and C.H.I.P.) and the behaviour was the same.
I used the example drivers from https://github.com/openthread/openthread/tree/master/examples/platforms/kw41z.

• The NCP for border router was built with BORDER_ROUTER=1 JOINER=1 COMMISSIONER=1 TMF_PROXY=1 flags.
• CLI device was built with JOINER=1 COMMISSIONER=1 flags.

Commissioning with two CLI devices without OTBR works well. Can you please give me some advice where should be a problem or what should I do to identify it. I've spent a few days searching and debugging and found no solution. I followed the guide (https://openthread.io/guides/border_router/build), did I miss something? Thank you.

I have just installed borderrouter on my Raspberry Pi which was previously running wpantund, I followed the installation guide in the wiki and it appears to have worked (can access the web interface), except I cannot connect to the NCP device, my assumption is that this is because wpantund is connecting to the wrong serial device.

The README states that I can configure wpantund with the file/etc/wpantund.conf, however this file does not exist.

I'm not sure if this failed to be created because of a bug somewhere or what the issue is.

We (TI) are getting ready to push up border router support for the Beagle Bone Black - and want to know what is the process to contribute additional information in the border router wiki on the openthread.io? wiki page?

Thanks.

It would be a great oportunity to support borderrouter project in a raspberry pi builded with Android Things image. Android Things is a platform based on Linux kernel that makes easy to create iot devices which can communicate easily with each other and with other platforms such as android phones, windows or ios

npm WARN deprecated [email protected]: ..psst! While Bower is maintained, we recommend yarn and webpack for new front-end projects! Please read our blog for more.

Originally reported by Stuart Longland from openthread-users.

Some things I've noticed while building.

First, I think ctags is not needed to build this.

Second, nodejs bower package is needed, so

sudo apt-get install -y nodejs
npm install -g bower

should be added.

Third, bower seems to be deprecated: npm WARN deprecated [email protected]: ..psst! While Bower is maintained, we recommend yarn and webpack for new front-end projects! Please read our blog for more.

Fourth, the service names do not match, i.e. it should be otbr-agent and otbr-web

Hmm - Examples and such generally assume the border router is usable in a 192.168.0.0/16 range

Some routers only provide (default to) a 192.168.0.0/24 range.

Example: DLINK : http://support.dlink.com/emulators/dir601/100NA/lan.html

Others require two sub ranges, Range (A) for the normal access and Range(B) for the guest network range (while others do this another way)

Example: CradelPoint (3G type solution)

http://knowledgebase.cradlepoint.com/articles/Support/Manual-Network-Settings-WiFi-Local-Networks

In this case, they have (require) two non-overlaping IP address ranges, one for internal network and another for the guest network.

Other routers (ie: Netgear provide 10.0.0.0 address ranges [I have this at home])

I think the documentation needs to point this out.

Bug 1

In early June - this the border router ./;configure script parameters for the border router changed
See: openthread/openthread#1883

However, the test script: ${borderrouter}/tests/meshcop/meshcop still uses the old ./configure options

https://github.com/openthread/borderrouter/blob/master/tests/meshcop/meshcop#L72

Bug 2

Due to the way the scripts are written, a number of things are executed in the background ins ome cass with a & (ampersand) to place it in the background, or they are written using sub shells, or via sudo

if the application "dumps core" for any reason, or exits with a non-zero result - the existing script still exits with a zero result, or - the end result is the error is not captured.

Bug 3

Scripts that execute in a sub shell, for example in (parens) that have errors are not propigating error/exit values up and resulting in a true error

All of these are addressed here: #92

While the scripts check for CTAGs to be present... (exuberant ctags)

if CTAGs is not actually present, the build does not work very well.

Short term:
Configure should fail if ctags are not present
Long term:
It needs a fix.

the password is needed when connect to border router demo, what is the password?

What should happen is - here at:

https://github.com/openthread/borderrouter/blob/master/src/agent/dtls_mbedtls.hpp#L224

In the MbedtlsServer() Constructor, the member variable: 'mSocket' should be initialized to (-1)

Instead, it takes on a RANDOM value based upon what ever the run time environment leaves there.

What happens later, during the call to void MbedtlsServer::UpdateFdSet()

Code: https://github.com/openthread/borderrouter/blob/master/src/agent/dtls_mbedtls.cpp#L411

The RANDOM value is used as a BIT index into the various FDSETS - which then has a 50/50 chance of flipping a bit somewhere on the run-time stack.

I say 50/50 - because the bit may already be 1, and the operation here is to SET the bit, the best part of this: Is if you change the code to debug this the problem has a chance of moving, or going away.

What happens sometimes (especially in the commissioner test application) the first call to the void MbedtlsServer::UpdateFdSet() the socket is not yet open, very soon after - and and this depends on other timing items, mSocket is initialized with some valid socket number.

The problem occurs here:

https://github.com/openthread/borderrouter/blob/master/src/agent/dtls_mbedtls.cpp#L458

Note: Appropriate "valid-fd-test" needs to be inserted at the FD_SET operation

FYI @pkanek & @srickardti

In this commit: PR: "enable raspbian check #41"

Introduced problems to the bootstrap script

For example, line 40 reads:

test "$RELEASE" = 1 || sudo install cmake

That does not work.

Using a FRESH raspbian image, on a RaspberryPI 3 B+ using this image:

$ sha1sum.exe 2017-04-10-raspbian-jessie-lite.*
dad2ba8a228f14e64af7d80e1fd2503facb70c61 *2017-04-10-raspbian-jessie-lite.img
c24a4c7dd1a5957f303193fee712d0d2c0c6372d *2017-04-10-raspbian-jessie-lite.zip

The error message I get is this (in contrast, the Beagle Bone Black) goes past this step.
perhaps, when these docs where written the NodeJS package was already installed?
And thus the script skipped over this part?

## Installing the NodeSource Node.js v6.x repo...

## You appear to be running on ARMv6 hardware. Unfortunately this is not currently supported by 
the NodeSource Linux distributions. Please use the 'linux-armv6l' binary tarballs available
directly from nodejs.org for Node.js v4 and later.

pi@raspberrypi:~/borderrouter$

Hi,
when I followed the steps showed in "https://github.com/openthread/borderrouter/wiki" and try to build the environment of border router on ubuntu(virtual machine) with cc2538(NCP), I can't open web page "http://127.0.0.1:8080/web/frontend/app/#".

The environment:
1.CC2538 driver has been installed.
root@robot-VirtualBox:/home/robot/tinyara/borderrouter-master# ls /dev | grep ttyUSB
ttyUSB0
ttyUSB1

2. ./scrip/server
   Current platform is ubuntu

• Applying /etc/sysctl.d/10-console-messages.conf ...
  kernel.printk = 4 4 1 7
• Applying /etc/sysctl.d/10-ipv6-privacy.conf ...
  net.ipv6.conf.all.use_tempaddr = 2
  net.ipv6.conf.default.use_tempaddr = 2
• Applying /etc/sysctl.d/10-kernel-hardening.conf ...
  kernel.kptr_restrict = 1
• Applying /etc/sysctl.d/10-link-restrictions.conf ...
  fs.protected_hardlinks = 1
  fs.protected_symlinks = 1
• Applying /etc/sysctl.d/10-magic-sysrq.conf ...
  kernel.sysrq = 176
• Applying /etc/sysctl.d/10-network-security.conf ...
  net.ipv4.conf.default.rp_filter = 1
  net.ipv4.conf.all.rp_filter = 1
  net.ipv4.tcp_syncookies = 1
• Applying /etc/sysctl.d/10-ptrace.conf ...
  kernel.yama.ptrace_scope = 1
• Applying /etc/sysctl.d/10-zeropage.conf ...
  vm.mmap_min_addr = 65536
• Applying /etc/sysctl.d/60-otbr-ip-forward.conf ...
  net.ipv6.conf.all.forwarding = 1
  net.ipv4.ip_forward = 1
• Applying /etc/sysctl.d/99-sysctl.conf ...
  active
  active
  activating

3.The network proxy of the system and firefox has been closed.

But when I input "http://127.0.0.1:8080/web/frontend/app/#" in firefox, the web page returns "Unbale to connect". I can't find the fail reason and could you please help me to find what causes this failure?
Thanks a lot!

It would be useful to display the status of important services (e.g. up/down), such as wpantund.

I'm building the borderrouter with ctags (GNU Emacs 24.2) and when the version file for libcoap is generated, I get this:

( /usr/local/bin/ctags -I "coap_packet_extract_pbuf coap_pdu_from_pbuf" -f - --c-kinds=p ./include/coap/address.h ./include/coap/async.h ./include/coap/bits.h ./include/coap/block.h ./include/coap/coap.h ./include/coap/coap_io.h ./include/coap/coap_time.h ./include/coap/debug.h ./include/coap/encode.h ./include/coap/hashkey.h ./include/coap/libcoap.h ./include/coap/mem.h ./include/coap/net.h ./include/coap/option.h ./include/coap/pdu.h ./include/coap/prng.h ./include/coap/resource.h ./include/coap/str.h ./include/coap/subscribe.h ./include/coap/uri.h ./include/coap/uthash.h ./include/coap/utlist.h | awk '/^coap_/ { print $1 }' | sort ) \
> libcoap-1.sym.new
/usr/local/bin/ctags: unrecognized option '--c-kinds=p'
/usr/local/bin/ctags: unrecognized option '--c-kinds=p'
	Try `/usr/local/bin/ctags --help' for a complete list of options.
	Try `/usr/local/bin/ctags --help' for a complete list of options.
mv libcoap-1.sym.new libcoap-1.sym
libtool: link: rm -fr  .libs/libcoap-1.ver
libtool: link: echo "{ global:" > .libs/libcoap-1.ver
libtool: link:  cat ./libcoap-1.sym | sed -e "s/\(.*\)/\1;/" >> .libs/libcoap-1.ver
libtool: link:  echo "local: *; };" >> .libs/libcoap-1.ver
libtool: link:  gcc -shared  -fPIC -DPIC  src/.libs/libcoap_1_la-address.o src/.libs/libcoap_1_la-async.o src/.libs/libcoap_1_la-block.o src/.libs/libcoap_1_la-coap_io.o src/.libs/libcoap_1_la-coap_time.o src/.libs/libcoap_1_la-debug.o src/.libs/libcoap_1_la-encode.o src/.libs/libcoap_1_la-hashkey.o src/.libs/libcoap_1_la-mem.o src/.libs/libcoap_1_la-net.o src/.libs/libcoap_1_la-option.o src/.libs/libcoap_1_la-pdu.o src/.libs/libcoap_1_la-resource.o src/.libs/libcoap_1_la-str.o src/.libs/libcoap_1_la-subscribe.o src/.libs/libcoap_1_la-uri.o    -g -O2   -Wl,-soname -Wl,libcoap-1.so.0 -Wl,-version-script -Wl,.libs/libcoap-1.ver -o .libs/libcoap-1.so.0.0.0
/usr/bin/ld:.libs/libcoap-1.ver:2: syntax error in VERSION script

The content of ./third_party/libcoap/repo/.libs/libcoap-1.ver is:

{ global:
local: *; };

Shouldn't the configure script fail when the --c-kinds option is not available?
What is the correct ctags version to use?

Added wiki page for NAT64 configuration. NAT64

@lanyuwen @jwhui

Here:

https://github.com/openthread/borderrouter/blob/master/script/_otbr#L50

In the scripts directory, make is invoked with the number of processors for the "-j" parameter.

On a reduced target such as a Beagle Bone runs out of memory when compiling things.

• RaspberryPi => 1GIG ram
• BeagleBone => 512MEG ram.

for example:

  CXX      wpan-controller/libotbr_web_la-dbus_scan.lo
  CXX      wpan-controller/libotbr_web_la-dbus_ifname.lo
  CXX      wpan-controller/libotbr_web_la-wpan_controller.lo
  CXX      mdns-publisher/libotbr_web_la-mdns_publisher.lo
  CXX      pskc-generator/libotbr_web_la-pskc.lo
  CXX      web-service/libotbr_web_la-web_service.lo
[59433.551382] Out of memory: Kill process 21993 (cc1plus) score 707 or sacrifice child
[59433.559409] Killed process 21993 (cc1plus) total-vm:369304kB, anon-rss:352000kB, file-rss:712kB
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
Makefile:839: recipe for target 'web-service/libotbr_web_la-web_service.lo' failed
make[3]: *** [web-service/libotbr_web_la-web_service.lo] Error 1
Makefile:425: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
Makefile:556: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
Makefile:481: recipe for target 'all' failed
make: *** [all] Error 2
debian@beaglebone:~/borderrouter$

Could be done by adding an option to the install scripts

I believe there are 2 issues here.

Issue 1 is in the Agent, described here.

Issue 2 is in the embedded side, where the Commissioning Petition is actually handled (there is no provision for duplicate message detection) I believe there should be.
Described here: openthread/openthread#2037

Short Description: The Agent does not seem to handle PROXY requests correctly.
By correctly, I specifically mean with the ability to detect duplicate COAP requests.

Example:
https://github.com/openthread/borderrouter/blob/master/src/agent/border_agent.cpp#L102

When a commissioner request is created (example: by the android app) the message is received with both a OPAQUE tag, and a MESSAGE ID - per RFC7252 - Section 2.1 - the Message ID is used to detect duplicates.

However, when the message is forwarded - a call is made to mCoap->NewMessage(), which results in a NEW message id for each forwarded message, See:

https://github.com/openthread/borderrouter/blob/master/src/agent/coap_libcoap.cpp#L150

If the commissioner (ie: The Android App) sends a duplicate CoAP petition, each forwarded message has a "unique message id" - thus when the leader receives the petition - each comes with a unique message id and thus there is NO means for the Leader to detect a duplicate request.

I'm not sure of the correct solution here,

option (1) would be to duplicate (pass through) the message original message ID,

or

Option (2) in the agent, mapping of the "android-app-message-id" vrs "proxy-message-id"

Separately, there's an issue with the embedded leader where it does not handles duplicate commissioning CoAP requests. More generally - in the embedded side I think some common scheme to handle duplicate message detection is an important feature that is missing, while this problem was noticed in the commissioning process at the application layer there is a strong need for duplicate message detection.

I've noticed that from about week ago DHCPv6 PD doesn't work properly. Today I've spent some time on investigation this problem and I've found reason. Few days ago there were dhcpcd5 update in raspbian repository (from version: 1:6.11.5-1+rpt2 to version 1:6.11.5-1+rpt4). An update provide some fixes, unfortunatly one fix provides improvement that can be very harmful because it assume that every interface which first letter is equal to "w" is a wireless interface, so wpan0 is treated as wireless interface and dhcpcd5 can't get carrier for this interface, so it say that it is not connected and can't delegate IPv6 prefix to it. Below I've put mentioned change.

--- a/if.c
+++ b/if.c
@@ -534,7 +534,7 @@
                /* We reserve the 100 range for virtual interfaces, if and when
                 * we can work them out. */
                ifp->metric = 200 + ifp->index;
-               if (if_getssid(ifp) != -1) {
+               if (if_getssid(ifp) != -1 || *ifp->name == 'w') {
                        ifp->wireless = 1;
                        ifp->metric += 100;
                }

There is few options that allow us to solve this problem.

1. Because I haven't managed to install previous version from apt-get, there is an option to commit working DEB with dhcpcd5 to git repository and install it via dpkg during border router installation. It is the easiest solution. This option allow avoid similar situations in the future.
2. Second option is to inform an author and wait for fix (if he decide to fix it).

I've tried to fixit by changes in config file but unfortunatly I haven't found working solution. So I've decided to abandon this idea and ask what do you think about first solution that seems to be the most bullet proof solution?

The new check can avoid issue fixed in #96 .

What is the plan for "off-platform" (ie: off raspberry pi, or beagle bone) devices to find a route to the thread network? What I mean is this:

Consider the following:

• The Thread Network has on-network prefix (T)
• My home office network has prefix (H) [in my case provided by AT&T Uverse
• Thus my BBB (or raspberry pi) has two interfaces with address (H) and (T).

My cellphone, and laptop only have a HOME network prefix (H), how do they find a
route to the Threadnetwork with prefix (T)?

I was expecting to see a /etc/rdavd.conf setup.

Am I missing something?

I think this is more of a "development board problem" then an actual product problem.

Many development boards use a USB Serial port for communications to the NCP. Actual physical products will probably reduce cost, and use a dedicated hardware serial port, or SPI interface.

At boot - different platforms enumerate USB interfaces at different rates, and depending upon if a USB hub is present, and what is plugged into the HUB ... as a result: there could be a long time before all USB devices are enumerated.

However, the wpantund service often starts before the actual device is starting.

Possible solutions - wrap the wpantund service in a wait-script that waits with a timeout (ie: 10 seconds?) for the serial port to actually appear.

Or do the wait inside of wpantund

Or ... this gets really complicated, configure the service request to wait on the specific USB events but that would be very complex to generalize to all platforms, all devices etc.

I've made pull request with support for Network Manager as a first step for simplifying WiFi management. I'm going to continue my work in this area and currently I want ask you about help to make a decision what is the approach.

There are available two approaches:

1. Extend an existing Border Router control panel. There will be supported only basic functionalities that allow to connect and disconnect, setup AP, setup password.
2. Use some available OpenSource WebGUI for Network Manager (e.g. https://github.com/mk-fg/NetworkManager-WiFi-WebUI?files=1)

What do you think about this idea? Do you have any opinion about that?

I think we should add some basic functional tests for web. To make this happen, I think we should have the following changes,

1. support set listening port at runtime instead of hard coded 80.
2. support set location of front-end files at runtime instead of fixed at compiling time.
3. document HTTP APIs.

To start with, I'm not a UDP socket guy - but I think I found a problem dealing with the dtls server in the border router agent, and the commissioning test app

My initial tests (with a fix) seem to be indicate I am correct, but I have not completed my testing.

Step 1: In the main loop, various 'pseudo' tasks are called to set their bits in a select( ... fd_set ... )

This occurs here, in the commissioner test app:
https://github.com/openthread/borderrouter/blob/master/tests/meshcop/commissioner.cpp#L655

In the AGENT, it occurs here:
https://github.com/openthread/borderrouter/blob/master/src/agent/main.cpp#L68

Step 2: The main loop then calls select, either select times out, or something is readable/writable, etc.

Step 3: The main loop then calls all of the 'pseudo-tasks' - asking them to examine their SelectBits.

I think I see a problem in in the MbedtlsServer::ProcessServer() function, the code does this:

SEE: https://github.com/openthread/borderrouter/blob/master/src/agent/dtls_mbedtls.cpp#L491
snippit below

void MbedtlsServer::ProcessServer( ... )
{
     /* .. snip ... */
     otbrError   error = OTBR_ERROR_ERRNO;
     /* .. snip ... */

    // I THINK THIS IS WRONG...
    VerifyOrExit(recvmsg(mSocket, &msghdr, MSG_PEEK) > 0);

    [ snip ... process the request ...]

exit:
    // abbreviated version...
    if( error ){
           close_socket()
           reopen_socket()
     }
}

I think this is wrong because:

SHORT VERSION

Step A - During the JOINING process, the JOINER sends a RELAY request that is eventually will end up back at the Commissioner

Step B - To do that, when the RELAY request is received, it is decrypted and forwarded -

example in the commissioner test application, here:
https://github.com/openthread/borderrouter/blob/master/tests/meshcop/commissioner.cpp#L212

In the agent, it occurs here (tx & rx are next to each other):
https://github.com/openthread/borderrouter/blob/master/src/agent/border_agent.cpp#L141

Step C - KEY POINT Depending upon timing, that message may or may-not be ready on the relay socket when select is called, due to this issue, the socket is closed & reopened thus the message may or may not be lost. (without a fix, I see the message lost quite often, but it is moody sometimes it works, sometimes it fails always ... Grr...)

LONG VERSION

• Initial conditions, when SELECT returns in the main loop
  • DTLS message is ready on Socket (A) - the secure socket.
  • Nothing is ready on Socket (B) - the non secure socket.
• The process loop runs, we come to the dtls pseudo-process.
  • The FD_ISSET() == true for Socket(A) -
  • The message is received and decrypted
  • The message is then forwarded to Socket (B)
• Depending upon TIMING
  * Case (A) The forwarded message may be "in-transit"
  * Case (B) OR - the message has arrived at the socket quickly.
  * In any event, select() was not called again.
• What would cause big timing differences? Why do I see this?
  • I think it is due to network traffic volume .. and this is only a SWAG...
  • In my environment, I only have my RaspBerryPi/BeagleBone + WifiRouter
    * Thus, my environment is super calm from a network point of view.
  • In the Travis Environment, I presume the data center has LOTS of network activity to sort
  • Other offices and/or test environments may be just as noisy
• Eventually the Process Loop gets to the mbed code (above) that I think is wrong.
  * because FD_ISSET(socket B) is FALSE - the VerifyOrExit() goes to EXIT
  * At the exit: label, if an ERROR occurs - the socket is CLOSED
  * See: https://github.com/openthread/borderrouter/blob/master/src/agent/dtls_mbedtls.cpp#L538
• Because the socket is closed
  * In case A - the forwarded message is NOT LOST because it is in transit and not yet delivered
  * In case B - the waiting message is LOST
  * Again - i'm not a UDP guy, but as I understand a closed socket drops all packets.
  * My reference is here: Reference: https://stackoverflow.com/questions/7843644/how-long-does-a-udp-packet-stay-at-a-socket
  * In case B - the message SHOULD be re transmitted after a timeout.
  * In case B - maybe the 2nd time is a charm and it works... or it is a random test failure
• In case A (the message is "in-transit" and not lost)
  * In the working situation, the code loops around Select is called again
  * Again due to timing -
  * the socket is CLOSED and REOPENED
  * In the successful case, I assume this occurs quickly
  * ie: before the message is delivered by the kernel to the socket
  * The second time around, the FD_ISSET() is true - and the socket is not closed.

FYI: @pkanek and @srickardti

https://opensource.google.com/projects/openthread includes OpenThread and wpantund. It should also include this project. @Vyrastas