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

[Piotr Szkotak]

Hi Mary,

At the first glance it looks fine.

Let's start from checking connectivity at the RPi.

1. Can you 'ping 8.8.8.8' from the Raspberry?

I see that you have global IPv6 connectivity. 

2. Can you 'ping6 2001:4860:4860::8888' from the Raspberry?

3. In case of CLI we can also try 'ping 2001:4860:4860::8888'?

 

Please let me know what is output of these three commands.

What provides network connection to the Raspberry? Is it the same as for your PC?

Kind Regards,

Piotr Szkotak

[Mary]

1.  Yes, I can ping 8.8.8.8 from Raspberry Pi

pi@raspberrypi:~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=31.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=32.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=36.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=58 time=30.5 ms

2. Yes, I can ping6 from Raspberry Pi

pi@raspberrypi:~ $ ping6 2001:4860:4860::8888
PING 2001:4860:4860::8888(2001:4860:4860::8888) 56 data bytes
64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=58 time=31.5 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=2 ttl=58 time=32.3 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=3 ttl=58 time=30.5 ms
64 bytes from 2001:4860:4860::8888: icmp_seq=4 ttl=58 time=31.6 ms

3. ping from CLI returned nothing

> ping 2001:4860:4860::8888
>

Raspberry Pi is connected to our office network via Ethernet cable, through a switch to our router.  

Raspberry Pi network configuration as reported by the router:

My PC is connected in similar fashion, though the same switch to the same router.

Mary

[Mary]

On the 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

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

pi@raspberrypi:~ $ sudo tcpdump -i wpan0 ip6
sudo: tcpdump: command not found

I reflashed both the CLI and NCP projects. Same results.

How do I get tcpdump?

[Piotr Szkotak]

sudo apt-get update && sudo apt-get install tcpdump

We see that packet does not even reach the eth0 interface, that is interesting.

[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

 

[Mary]

1. RaspPi

pi@raspberrypi:~ $ ip -6 route
64:ff9b::/96 dev nat64 metric 1024  pref medium
2600:xxxx:xxxx:96c0::/64 dev eth0 proto kernel metric 256  expires 1209485sec pref medium
2600:xxxx:xxxx:96c9:1000::/68 dev wpan0 proto kernel metric 204  pref medium
unreachable 2600:xxxx:xxxx:96c9::/64 dev lo metric 201  error -113 pref medium
fd11:22::/64 dev wpan0 proto kernel metric 256  pref medium
fdaa:bb:1::1 dev nat64 proto kernel metric 256  pref medium
fdde:ad00:beef::/64 dev wpan0 proto kernel metric 256  pref medium
fe80::/64 dev wlan0 proto kernel metric 256  pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
fe80::/64 dev wpan0 proto kernel metric 256  pref medium
fe80::/64 dev nat64 proto kernel metric 256  pref medium
default via fe80::e222:4ff:fe91:86b9 dev eth0 proto ra metric 1024  expires 1685sec hoplimit 64 pref medium

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

<Nothing on RaspPi>

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

<Nothing on RaspPi>

tcpdump -i eth0 -nv icmp6 or icmp and ping

<Nothing on RaspPi>

We will look into adjusting the prefix length at the router.

Mary

[Mary]

We have an AT&T router that assigned 64 bit prefixes.  We don't seem to be able to change that.  Is Thread configurable in this regard?  Is it possible to set it to use a longer prefix?

[Mary]

From this page

NoteWhen dealing with native IPv6 connectivity, make sure you use the DHCPv6 service, and not the popular Stateless Address Autoconfiguration (SLAAC) tool. This autoconfig tool will only provide a 64-bit long prefix that is not sufficient to delegate a new 64-bit long prefix for the Thread network.

Do they mean on the RaspPi?  Is the image I downloaded not already set up properly? How can I check?