This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Thread border router 1.0.0

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

  • 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 

  • 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

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

  • 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

  • It seems you used:

    ip4.google.com instead of ipv4.google.com

     

     

Related