Thread border router 1.0.0

[Mary]

I am following the Thread Border Router example and have successfully loaded RaspPi_OT_Border_Router_Demo_v1.0.0-1.alpha.img onto the RaspberryPi 3B+.

I have loaded the NCP example onto a Nordic Semi nRF52840 development board, and connected it the the Raspberry Pi.  I have loaded the CLI example onto another development board.

I can successfully ping between the two Thread nodes, but not outside to my PC or to google as described in the example.

I am using nRF_SDK_for_Thread_and_Zigbee_v1.0.0

Rasp Pi:  border_router.conf

# Thread Network Configuration
thread_network_key="00112233445566778899AABBCCDDEEFF"
thread_channel="11"
thread_panid="0xABCD"
thread_xpanid="DEAD00BEEF00CAFE"
thread_network_name="NordicOpenThread"
thread_pskc="E00F739803E92CB42DAA7CCE1D2A394D"
thread_on_mesh_prefix="fd11:22::"

Rasp Pi: ifconfig:

pi@raspberrypi:/etc $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.72  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2600:XXXX:XXXX:96c0:ba27:ebff:fe94:7933  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::ba27:ebff:fe94:7933  prefixlen 64  scopeid 0x20<link>
        inet6 2600:xxxx:xxxx:96c0::5c5  prefixlen 128  scopeid 0x0<global>
        ether b8:27:eb:94:79:33  txqueuelen 1000  (Ethernet)
        RX packets 6104  bytes 545078 (532.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5457  bytes 1174736 (1.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


nat64: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 192.168.255.1  netmask 255.255.255.255  destination 192.168.255.1
        inet6 fdaa:bb:1::1  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::73b8:21d2:47dc:cf7  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4  bytes 304 (304.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


wpan0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
        inet6 fd11:22::540c:ed30:4494:6a9c  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::540c:ed30:4494:6a9c  prefixlen 64  scopeid 0x20<link>
        inet6 fe80::3bdd:44c5:d59c:102e  prefixlen 64  scopeid 0x20<link>
        inet6 fdde:ad00:beef:0:a610:e28d:369:454e  prefixlen 64  scopeid 0x0<global>
        inet6 2600:XXXX:XXXX:96c9:1000::1  prefixlen 68  scopeid 0x0<global>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 1  bytes 56 (56.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 10  bytes 1371 (1.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

CLI node:

>ipaddr
2600:XXXX:XXXX:96c9:ee61:43f6:eb74:b3e8
fd11:22:0:0:29e0:308e:1b41:a566
fdde:ad00:beef:0:0:ff:fe00:fc00
fdde:ad00:beef:0:0:ff:fe00:6800
fe80:0:0:0:8803:5bb9:52c6:1591
fdde:add0:beef:0:35da:1ab0:72b9:2919

The suggested command on the CLI node to test

>ping 64:ff9b::0808:0808

returns nothing

The following (and many other combinations) also return nothing:

>ping 2600::XXXX:XXXX:96c9::0808:0808

>ping fdde:ad00:beef::0808:0808

But this one succeeds

>ping fd11:22::540c:ed30:4494:6a9c

returns "8 bytes from fd11:22:0:0:540c:ed30:4494:6a9c: icmp_seq=5 hlim=64 time=74ms"

The ipv6 prefixes do not seem to match on the Raspberry Pi and the CLI node:

RaspPi eth0:      inet6 2600::XXXX:XXXX:96c0:ba27:ebff:fe94:7933  prefixlen 64  scopeid 0x0<global>

RaspPi wpan0:  inet6 2600::XXXX:XXXX:96c9:1000::1 prefixlen 68 scopeid 0x0<global>
 

Is this correct?  If not, how to fix it?

Mary

[Mary]

I got tcpdump.

CLI:

> ping fdde:ad00:beef:0:a610:e28d:369:454e
> 8 bytes from fdde:ad00:beef:0:a610:e28d:369:454e: icmp_seq=1 hlim=64 time=33ms

RaspPi

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wpan0, link-type RAW (Raw IP), capture size 262144 bytes
15:31:26.377995 IP6 fdde:ad00:beef:0:3c36:a6bf:1720:da2f > fdde:ad00:beef:0:bf2f:9691:b564:f8cd: ICMP6, echo request, seq 3, length 16
15:31:26.378315 IP6 fdde:ad00:beef:0:bf2f:9691:b564:f8cd > fdde:ad00:beef:0:3c36:a6bf:1720:da2f: ICMP6, echo reply, seq 3, length 16

CLI:

> ping 2600:xxxx:xxxx:96c0::5c5
>

RaspPi

<nothing at all>

[Mary]

Does Commissioning have to be done first?

[Mary]

Several minutes later this appeared on the Rasp Pi:

15:37:51.000429 IP6 2600:xxxx:xxxx:96c9:1000::1.48378 > ff33:40:fdde:ad00:beef::1.47193: UDP, length 5

[Mary]

Is someone working on this? It's an important feature for our project.

[Piotr Szkotak]

These examples are precommissioned. The communication between CLI and NCP is fine.

In such case there is no need to perform commissioning.

I think that we need to split the communication issue into two parts:

1. Native IPv6 not working. (2600 prefix).

2. NAT64 communication not working (64:ff9b prefix).

Regarding the 1. I see that router assigned prefix /64 to the raspberry. If this is really true the Thread should not even obtain this prefix as it is too long. The Thread itself needs /64, meaning that the raspberry should get shorter one, e.g. /62 to bo able to exclusively give /64 to Thread.

We can confirm length of obtained prefix by checking the routing table on the raspberry with 'ip -6 route'.

There you will see 26xx prefix on eth0 with its length in a form:

2600:aaaa:bbbb:cccc::/64 dev eth0 proto ra metric 100 pref medium

/64 means we are out of luck.

In case of NAT64 the traffic on the raspberry is handled differently. There is additional nat64 interface involved. In this case the IPv6 packets go from wpan0 interface to nat64 where translation to IPv4 takes place and IPv4 packets go to the eth0 or wlan0 depending if wired or wireless connection is used.

In this case we should track packets when using 64:ff9b destination.'ping 64:ff9b::808:808' is excellent as the destination is in fact Google's 8.8.8.8 IPv4 address embedded in IPv6 address. I highly recommend pinigng 64:ff9b::0808:0808 from the CLI and checking IPv6 traffic on wpan0 and nat64 interfaces and IPv4 traffic on nat64 and eth0.

 

I would execute 'tcpdump -i wpan0 -nv icmp6 or icmp' and ping 64:ff9b::808:808 from CLI.

then tcpdump -i nat64 -nv icmp6 or icmp and ping again,

and tcpdump -i eth0 -nv icmp6 or icmp and ping the last time.

 

Kind regards,

Piotr