OpenThread border router On-Mesh Prefix

[Stuart Longland]

Hi all,

Silly question, I'm busy testing out the OpenThread border router, and I
think with my .deb packages, I have it bundled up and installed the way
it was intended.

So far, I'm able to have wpantund bring up the WPAN on boot, and able to
manage it from the UI over HTTP. All good. However, it seems that the
border router when ticked as the 'default router' does not expose itself
as such to the nodes.

Thus, the nodes can ping the border router, but if I configure another
host with a route to the WPAN via the border router and try pinging a
node from that host, the nodes do not reply. Nor do they successfully
ping the outside host.

Furthermore, I tried setting up the On-Mesh Prefix with a public IPv6
subnet which I was going to route to the Internet.

While my workplace's ISP lives in the dark ages, I do have dual-stack
Internet at home with an OpenVPN tunnel between my workstation and my
home network and 256 /64 subnets to play with. Thus the plan was to
take one of those, route it via the home network and my workstation to
the border router, and see if one of the nodes could hit the public IPv6
internet.

In spite of specifying a valid public IPv6 subnet, nothing appears on
the nodes:

http://www.longlandclan.id.au/~stuartl/openthread/2017/08/29-otbr/otbr-prefix.png
shows the config I specified, and the resulting status.

This is the node on the WPAN.
>> ipaddr
> fd00:1122:3344:0:0:ff:fe00:d400
> fd00:1122:3344:0:f053:1e0:c62c:5a41
> fe80:0:0:0:5c21:cadc:5911:1525
> Done
>> state
> router
> Done

Is there something I'm missing?
--
_ ___ Stuart Longland - Systems Engineer
\ /|_) | T: +61 7 3535 9619
\/ | \ | 38b Douglas Street F: +61 7 3535 9699
SYSTEMS Milton QLD 4064 http://www.vrt.com.au

[Stuart Longland]

On 29/08/17 12:18, Stuart Longland wrote:
> Is there something I'm missing?

Out of interest, I tried configuring `radvd` to advertise a prefix and
route on the wpan0 interface. I see the LEDs on the NCP indicating it
is receiving the advertisments, but it would appear the nodes don't know
anything about them.

[Stuart Longland]

On 29/08/17 13:15, Stuart Longland wrote:
> On 29/08/17 12:18, Stuart Longland wrote:
>> Is there something I'm missing?
>
> Out of interest, I tried configuring `radvd` to advertise a prefix and
> route on the wpan0 interface. I see the LEDs on the NCP indicating it
> is receiving the advertisments, but it would appear the nodes don't know
> anything about them.
>

This is what it looks like on the nodes when I try pinging the outside
world:

>> ping ff02::2
>> 8 bytes from fe80:0:0:0:483:8b7b:893:ae51: icmp_seq=5 hlim=64 time=15ms
>
>> ping ff02::2
>> 8 bytes from fe80:0:0:0:483:8b7b:893:ae51: icmp_seq=6 hlim=64 time=28ms
>
>> ping 64:ff9b::808:808
>> ipaddr
> fd00:1122:3344:0:0:ff:fe00:7002

> fd00:1122:3344:0:f053:1e0:c62c:5a41
> fe80:0:0:0:5c21:cadc:5911:1525
> Done

>> ping 2404:6800:4006:802::2004

… and on the router itself:

> root@wsg-74fe481fe117:~# ping6 -n 64:ff9b::808:808
> PING 64:ff9b::808:808(64:ff9b::808:808) 56 data bytes
> 64 bytes from 64:ff9b::808:808: icmp_seq=1 ttl=54 time=15.1 ms
> 64 bytes from 64:ff9b::808:808: icmp_seq=2 ttl=54 time=14.8 ms
> ^C
> --- 64:ff9b::808:808 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 14.899/15.039/15.179/0.140 ms
> root@wsg-74fe481fe117:~# ping6 -n www.google.com
> PING www.google.com(2404:6800:4006:806::2004) 56 data bytes
> 64 bytes from 2404:6800:4006:806::2004: icmp_seq=1 ttl=53 time=62.6 ms
> 64 bytes from 2404:6800:4006:806::2004: icmp_seq=2 ttl=53 time=85.7 ms

Configuration:
> root@wsg-74fe481fe117:~# ip6tables -nL FORWARD
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
> root@wsg-74fe481fe117:~# cat /proc/sys/net/ipv6/conf/all/forwarding
> 1
> root@wsg-74fe481fe117:~# cat /proc/sys/net/ipv4/ip_forward
> 1--

[Yakun Xu]

1. As you posted, it seems Thread node didn't get the on-mesh prefix you configured. Did you build the image with BORDER_ROUTER=1 and TMF_PROXY=1? If not, try building with these two FLAGS on and see if it works. more info

2. Thread nodes don't process RAs.

[Stuart Longland]

On 29/08/17 14:03, 'Yakun Xu' via openthread-users wrote:
> 1. As you posted, it seems Thread node didn't get the on-mesh prefix you
> configured. Did you build the image with BORDER_ROUTER=1 and
> TMF_PROXY=1? If not, try building with these two FLAGS on and see if it

> works. more info <https://github.com/openthread/borderrouter/wiki>

Ahh okay, so those translate to configure options:
--enable-tmf-proxy
and
--enable-border-router

I also noted JOINER=1 was in there, so added --enable-joiner too.

With that, it seems I'm still not able to ping the outside world. Is
there a way to inspect the routing table on the nodes (ala `ip -6 route`
on Linux or `route print` on OpenBSD)?

At times I also see this message in /var/log/daemon.log on the border
router:
> Aug 29 15:27:41 wsg-74fe481fe117 wpantund[373]: wpantund[373]: Resetting interface(s). . .
> Aug 29 15:27:41 wsg-74fe481fe117 wpantund[373]: Resetting interface(s). . .
> Aug 29 15:27:41 wsg-74fe481fe117 wpantund[373]: Finished initializing NCP
> Aug 29 15:27:41 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property NCP:State changed.
> Aug 29 15:27:41 wsg-74fe481fe117 wpantund[373]: wpantund[373]: Finished initializing NCP
> Aug 29 15:27:41 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property Daemon:ReadyForHostSleep changed.
> Aug 29 15:27:41 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property Daemon:ReadyForHostSleep changed.
> Aug 29 15:27:41 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property Network:PANID changed.
> Aug 29 15:27:41 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property Network:XPANID changed.
> Aug 29 15:27:41 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property IPv6:MeshLocalAddress changed.
> Aug 29 15:27:41 wsg-74fe481fe117 wpantund[373]: State change: "offline" -> "associating"
> Aug 29 15:27:41 wsg-74fe481fe117 wpantund[373]: wpantund[373]: State change: "offline" -> "associating"
> Aug 29 15:27:41 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property NCP:State changed.
> Aug 29 15:27:41 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property NCP:Channel changed.
> Aug 29 15:27:41 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property Network:Name changed.
> Aug 29 15:27:43 wsg-74fe481fe117 wpantund[373]: State change: "associating" -> "associated"
> Aug 29 15:27:43 wsg-74fe481fe117 wpantund[373]: Node type change: "unknown" -> "end-device"
> Aug 29 15:27:43 wsg-74fe481fe117 wpantund[373]: wpantund[373]: State change: "associating" -> "associated"
> Aug 29 15:27:43 wsg-74fe481fe117 wpantund[373]: wpantund[373]: Node type change: "unknown" -> "end-device"
> Aug 29 15:27:43 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property NCP:State changed.
> Aug 29 15:27:43 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property Network:NodeType changed.
> Aug 29 15:27:43 wsg-74fe481fe117 otbr-web[375]: otWeb[375]: wpan service error: 8
> Aug 29 15:27:43 wsg-74fe481fe117 otbr-agent[628]: otbr-agent[628]: NCP property Daemon:ReadyForHostSleep changed.
Quite what error 8 means, I am not sure.

For what it's worth, this is what I have in my Makefile (I build two
separate instances of OpenThread for the sake of memory consumption):

> NODE_TYPE=ftd
…
> # --- OpenThread build targets ---
>
> $(BUILD_DIR)/demo-lib/lib/libopenthread-$(NODE_TYPE).a \
> $(BUILD_DIR)/demo-lib/lib/libopenthread-cli-$(NODE_TYPE).a \
> $(BUILD_DIR)/demo-lib/lib/libopenthread-platform-utils.a \
> $(BUILD_DIR)/demo-lib/lib/libmbedcrypto.a: | \
> $(shell find $(OPENTHREAD_DIR) -type f -name \*.[ch])
> $(MAKE) -f $(TOP_DIR)/Makefile.ot \
> OPENTHREAD_BUILD_OPTS="\
> --with-platform-info=WIDESKYHUB \
> --enable-application-coap \
> --disable-docs --enable-joiner --enable-$(NODE_TYPE) \
> --enable-cli-app=$(NODE_TYPE) --disable-raw-link-api" \
> BUILD_DIR=$(BUILD_DIR)/demo/ot \
> INSTALL_DIR=$(BUILD_DIR)/demo-lib \
> NODE_TYPE=$(NODE_TYPE)
>
> $(BUILD_DIR)/ncp-lib/lib/libopenthread-$(NODE_TYPE).a \
> $(BUILD_DIR)/ncp-lib/lib/libopenthread-ncp-$(NODE_TYPE).a \
> $(BUILD_DIR)/ncp-lib/lib/libopenthread-platform-utils.a \
> $(BUILD_DIR)/ncp-lib/lib/libmbedcrypto.a: | \
> $(shell find $(OPENTHREAD_DIR) -type f -name \*.[ch])
> $(MAKE) -f $(TOP_DIR)/Makefile.ot \
> OPENTHREAD_BUILD_OPTS="\
> --with-platform-info=WIDESKYHUBNCP \
> --disable-docs --enable-$(NODE_TYPE) \
> --enable-ncp-app=$(NODE_TYPE) \
> --with-ncp-bus=uart --disable-raw-link-api \
> --enable-tmf-proxy --enable-border-router \
> --enable-joiner" \
> BUILD_DIR=$(BUILD_DIR)/ncp/ot \
> INSTALL_DIR=$(BUILD_DIR)/ncp-lib \
> NODE_TYPE=$(NODE_TYPE)

and in Makefile.ot:
> $(BUILD_DIR)/.configure: $(BUILD_DIR)/.bootstrap
> cd $(BUILD_DIR) && CXXFLAGS="$(CXXFLAGS) -Wno-unused-function" \
> $(OPENTHREAD_DIR)/configure \
> --host=arm-none-eabi --prefix=$(INSTALL_DIR) \
> $(OPENTHREAD_BUILD_OPTS)
> touch $@

I tried re-forming the network after flashing the updated firmware, and
even re-booting the border router, to no avail, it would appear the
nodes still don't know how to get beyond the border router.

[Yakun Xu]

1. From the logs you shared, it seems the firmware is still not right. Did you cleaned your work dir before re-building?

2. I don't think there's a option --enable-ftd  for configure. Adding non-existing option will not complete configure. Could you please check the scripts for configure and make sure the newly added flags actually take effect and try again?

[Stuart Longland]

Hi Yakun,

On 29/08/17 16:13, 'Yakun Xu' via openthread-users wrote:
> 1. From the logs you shared, it seems the firmware is still not right.
> Did you cleaned your work dir before re-building?

I have been… basically all the build files get put in a `build`
sub-directory, and I was blowing that away before build.

> 2. I don't think there's a option --enable-ftd for configure. Adding
> non-existing option will not complete configure. Could you please check
> the scripts for configure and make sure the newly added flags actually
> take effect and try again?

I can't recall exactly where I got --enable-ftd from… it could be a typo
from long ago, or it could be from what I saw in an earlier version of
OpenThread. For whatever reason, dropping that and rebuilding seems to
have got something working:

>> ipaddr
> fd00:1122:3344:0:0:ff:fe00:3400
> 2001:44b8:21ac:7059:2efa:939d:2d9a:ed56
> fe80:0:0:0:a011:368f:e134:9f4b

> fd00:1122:3344:0:f053:1e0:c62c:5a41

> Done
>> ping 2001:44b8:21ac:7053::1
>> 8 bytes from 2001:44b8:21ac:7053:0:0:0:1: icmp_seq=1 hlim=62 time=67ms
>> ping 2001:470:0:76::2
>> 8 bytes from 2001:470:0:76:0:0:0:2: icmp_seq=2 hlim=50 time=139ms

>> ping 64:ff9b::808:808

>> 8 bytes from 64:ff9b:0:0:0:0:808:808: icmp_seq=3 hlim=53 time=24ms
>> ping 2a03:2880:f101:83:face:b00c:0:25de
>> 8 bytes from 2a03:2880:f101:83:face:b00c:0:25de: icmp_seq=4 hlim=47 time=171ms

So it looks like we're on the Internet. Many thanks. :-)
Regards,

[Stuart Longland]

On 29/08/17 17:37, Stuart Longland wrote:
> So it looks like we're on the Internet. Many thanks. :-)
>

Having tried using this feature of the OpenThread border router, I'm
observing the following.

1. Entering the prefix with the subnet size (/64) silently breaks. The
UI accepts the value but the back-end does not assign the subnet. If
putting /64 in there is invalid, the UI should not accept it.

2. I find after a clean reboot of the border router, `wpantund` forgets
the on-mesh prefix, and I have to "form" the network again every boot,
which makes a mockery of the NCP having the settings in flash.

[Le Zhang]

Hi Stuart,

Thanks a lot for your suggestions, I will improve the functionality of the border router according to your suggestions.

Le