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]

I re-ran the tcpdum/ping tests and waited a bit.  I only got a response (and yes, delayed) for the eth0 test.

pi@raspberrypi:/etc $ sudo tcpdump -i eth0 -nv icmp6
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:39:00.763050 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 112) fe80::e222:4ff:fe91:86b9 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 112
        hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
          prefix info option (3), length 32 (4): 2600:xxxx:xxxx:96c0::/64, Flags [onlink, auto], valid time 1209600s, pref. time 1209600s
          route info option (24), length 24 (3):  2600:xxxx:xxxx:96c0::/60, pref=high, lifetime=1209600s
          rdnss option (25), length 24 (3):  lifetime 1200s, addr: 2600:1702:1d70:96c0::1
          mtu option (5), length 8 (1):  1500
          source link-address option (1), length 8 (1): e0:22:04:91:86:b9
15:39:01.489607 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ffbb:bcae: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:c895:87f1:1ebb:bcae
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.489610 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ffe0:ea4: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:ec1d:637f:b8e0:ea4
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.489612 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff4d:341b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:95a6:eefe:9f4d:341b
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.489614 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff83:1906: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:06c0:d987:6590:fb83:1906
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.489616 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff29:3c7c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:3ddd:7acd:5029:3c7c
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.489618 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff09:de88: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:7487:e816:d409:de88
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:01.491090 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff63:8caa: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:79a8:d89e:2e63:8caa
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.489602 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ffbb:bcae: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:c895:87f1:1ebb:bcae
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.489603 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ffe0:ea4: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:ec1d:637f:b8e0:ea4
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.490234 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff4d:341b: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:95a6:eefe:9f4d:341b
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.490237 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff83:1906: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:d987:6590:fb83:1906
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.490239 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff29:3c7c: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:3ddd:7acd:5029:3c7c
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.490241 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff09:de88: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:7487:e816:d409:de88
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1
15:39:02.490242 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) 2600:xxxx:xxxx:96c0:91d1:7b34:f74a:4e1 > ff02::1:ff63:8caa: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2600:xxxx:xxxx:96c0:79a8:d89e:2e63:8caa
          source link-address option (1), length 8 (1): 9c:eb:e8:19:c2:b1

Similar messages appeared periodically after these.

No, I have not modified the RaspPi at all, except to install tcpdump.

I will try WiFi on the Pi.

[Piotr Szkotak]

Unfortunately these are not ICMP echo request / echo response packets we hoped to see.

Let's perform one more test related to the persistent storage that may cause some issues.

On the CLI:

>factoryreset

On the RPi:

sudo wpanctl dataset erase && sudo reboot

after it boots you can connect to the wifi with:

wifi_connect WIFI_SSID WIFI_PASSWORD

then on the CLI:

> panid 0xabcd
Done
> ifconfig up
Done
> thread start
Done
> state
child
Done
> ipaddr
fdde:ad00:beef:0:0:ff:fe00:6403
fdde:ad00:beef:0:eb88:663:f303:3605
fe80:0:0:0:840f:5266:381:6e2f
Done
> dns resolve ipv4.google.com fdaa:bb:1::1
> DNS response for ipv4.google.com - [64:ff9b:0:0:0:0:d83a:d5ee] TTL: 300
ping 64:ff9b:0:0:0:0:d83a:d5ee
> 8 bytes from 64:ff9b:0:0:0:0:d83a:d5ee: icmp_seq=1 hlim=51 time=61ms

Please let me know if your results are different than mine.

Which board revision is being used (0.9.0/0.9.2/0.10.0/0.11.0)?

If different than 0.9.2 we highly recommend using usb/hex with the native USB port instead of communicationg over the Segger USB port.

Kind regards,

Piotr 

[Mary]

I was not able to connect the RaspPi to our wifi network.

I tried this method first, as described here. Our network is hidden and does not appear in the list returned by iwlist wlan0 scan. I know the SSID and password and used that.

wifi_connect mynetwork mypassword

The network settings remain unchanged and the BorderRouter-AP was still present, and even after rebooting the RaspPi.

pi@raspberrypi:~ $ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.42.0.1 netmask 255.255.255.0 broadcast 10.42.0.255
inet6 fe80::ba27:ebff:fec1:2c66 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:c1:2c:66 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 3 overruns 0 frame 0
TX packets 2893 bytes 738594 (721.2 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I also tried the method described here. I modified /etc/wpa_supplicant/wpa_supplicant.conf as described in the "Hidden Networks" section.

Again, the network setting remain unchanged and the BorderRouter-AP was still present, and even after rebooting the RaspPi.

That was yesterday.

Today I ran the steps you suggested:

On the RPi:

sudo wpanctl dataset erase && sudo reboot

after it booted,  connected to the wifi with:

wifi_connect WIFI_SSID WIFI_PASSWORD

pi@raspberrypi:~ $ ifconfig wlan0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.42.0.1 netmask 255.255.255.0 broadcast 10.42.0.255
inet6 fe80::ba27:ebff:fec1:2c66 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:c1:2c:66 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 4 overruns 0 frame 0
TX packets 222 bytes 51710 (50.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Still no wifi on the RaspPi

On the CLI:

> factoryreset

> panid
ffff
Done
> panid 0xabcd
Done
> ifconfig up
Done
> thread start
Done
> state
child
Done
> ipaddr
2600:xxxx:xxxx:96c9:749c:c6c0:3335:2885
fd11:22:0:0:a6f:3b1f:9593:a6db
fdde:ad00:beef:0:0:ff:fe00:5802
fdde:ad00:beef:0:3480:6ccc:eb32:87f3
fe80:0:0:0:707e:253d:f2ed:a6f8
Done
> dns resolve ip4.google.com fdaa:bb:1::1
> DNS response for ip4.google.com - Error 1: Failed

The board rev is 1.0.0 (as printed on the sticker).

Mary

[Mary]

Please obfuscate the global ipv6 address in the above post, as I have done elsewhere.

[Rob C]

Mary,

FWIW, I have had much better luck with DNS/Ping on my rPi Nordic OT Border Router (from SDK v1.0.0) by following the steps detailed under the "Enable forwarding" section of the page at https://openthread.io/guides/border-router/access-point.  I wonder whether the forwarding settings were really fully saved to persistent memory in the version provided by Nordic.

Note:  I am on an IPv4 connection, so this may not explain your problem, but I thought I'd share just in case.

Best, Rob