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

Parents
  • 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

  • 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

  • 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

     

     

  • Ran it all again:

    > factoryreset
    
    > panid
    ffff
    Done
    > panid 0xabcd
    Done
    > ifconfig up
    Done
    > thread start
    Done
    > state
    child
    Done
    > ipaddr
    2600:xxxx:xxxx:96c8:5c49:1be7:e5c3:dc3d
    fd11:22:0:0:fa16:b585:bb63:7219
    fdde:ad00:beef:0:0:ff:fe00:5801
    fdde:ad00:beef:0:4d70:1c94:f588:cb08
    fe80:0:0:0:9464:973f:8efc:f086
    Done
    > dns resolve ipv4.google.com fdaa:bb:1::1
    > DNS response for ipv4.google.com - [64:ff9b:0:0:0:0:acd9:c4e] TTL: 300
    ping 64:ff9b:0:0:0:0:acd9:c4e
    >
    

  • I tried adjusting some of my AT&T router settings.

    I disabled Prefix Delegation on the Settings->LAN->DHCP page.

    The CLI no longer has a global IPv6 address.

    I can now ping 64:ff9b::808:808 successfully from the CLI:

    > ipaddr
    fdde:ad00:beef:0:0:ff:fe00:c800
    fd11:22:0:0:98:1110:acd3:5d04
    fe80:0:0:0:9464:973f:8efc:f086
    fdde:ad00:beef:0:4d70:1c94:f588:cb08
    Done
    > ping 64:ff9b::808:808
    > 8 bytes from 64:ff9b:0:0:0:0:808:808: icmp_seq=17 hlim=55 time=58ms
    ping 64:ff9b::808:808
    > 8 bytes from 64:ff9b:0:0:0:0:808:808: icmp_seq=18 hlim=55 time=56ms
    ping 64:ff9b::808:808
    > 8 bytes from 64:ff9b:0:0:0:0:808:808: icmp_seq=19 hlim=55 time=56ms
    
    

    RaspPi

    pi@raspberrypi:~ $ sudo tcpdump -i wpan0 -nv icmp6
    tcpdump: listening on wpan0, link-type RAW (Raw IP), capture size 262144 bytes
    16:02:39.887719 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) fd11:22::98:1110:acd3:5d04 > 64:ff9b::808:808: [icmp6 sum ok] ICMP6, echo request, seq 17
    16:02:39.919365 IP6 (class 0x40, hlim 55, next-header ICMPv6 (58) payload length: 16) 64:ff9b::808:808 > fd11:22::98:1110:acd3:5d04: [icmp6 sum ok] ICMP6, echo reply, seq 17
    ^C
    2 packets captured
    2 packets received by filter
    0 packets dropped by kernel
    pi@raspberrypi:~ $ sudo tcpdump -i nat64 -nv icmp6
    tcpdump: listening on nat64, link-type RAW (Raw IP), capture size 262144 bytes
    16:03:33.559037 IP6 (hlim 63, next-header ICMPv6 (58) payload length: 16) fd11:22::98:1110:acd3:5d04 > 64:ff9b::808:808: [icmp6 sum ok] ICMP6, echo request, seq 18
    16:03:33.590472 IP6 (class 0x40, hlim 56, next-header ICMPv6 (58) payload length: 16) 64:ff9b::808:808 > fd11:22::98:1110:acd3:5d04: [icmp6 sum ok] ICMP6, echo reply, seq 18
    ^C
    2 packets captured
    2 packets received by filter
    0 packets dropped by kernel
    pi@raspberrypi:~ $ sudo tcpdump -i eth0 -nv icmp6
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    16:04:16.363805 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::18cb:c36e:34de:7939 > ff02::1:ff91:86b9: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::e222:4ff:fe91:86b9
              source link-address option (1), length 8 (1): 00:50:b6:64:09:c3
    16:04:33.365166 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::18cb:c36e:34de:7939 > ff02::1:ff91:86b9: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::e222:4ff:fe91:86b9
              source link-address option (1), length 8 (1): 00:50:b6:64:09:c3
    16:04:49.177597 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:xxxxxxxx: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
    ^C
    3 packets captured
    3 packets received by filter
    0 packets dropped by kernel
    pi@raspberrypi:~ $
    

    I'll try some other examples and see how it goes.

Reply
  • I tried adjusting some of my AT&T router settings.

    I disabled Prefix Delegation on the Settings->LAN->DHCP page.

    The CLI no longer has a global IPv6 address.

    I can now ping 64:ff9b::808:808 successfully from the CLI:

    > ipaddr
    fdde:ad00:beef:0:0:ff:fe00:c800
    fd11:22:0:0:98:1110:acd3:5d04
    fe80:0:0:0:9464:973f:8efc:f086
    fdde:ad00:beef:0:4d70:1c94:f588:cb08
    Done
    > ping 64:ff9b::808:808
    > 8 bytes from 64:ff9b:0:0:0:0:808:808: icmp_seq=17 hlim=55 time=58ms
    ping 64:ff9b::808:808
    > 8 bytes from 64:ff9b:0:0:0:0:808:808: icmp_seq=18 hlim=55 time=56ms
    ping 64:ff9b::808:808
    > 8 bytes from 64:ff9b:0:0:0:0:808:808: icmp_seq=19 hlim=55 time=56ms
    
    

    RaspPi

    pi@raspberrypi:~ $ sudo tcpdump -i wpan0 -nv icmp6
    tcpdump: listening on wpan0, link-type RAW (Raw IP), capture size 262144 bytes
    16:02:39.887719 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) fd11:22::98:1110:acd3:5d04 > 64:ff9b::808:808: [icmp6 sum ok] ICMP6, echo request, seq 17
    16:02:39.919365 IP6 (class 0x40, hlim 55, next-header ICMPv6 (58) payload length: 16) 64:ff9b::808:808 > fd11:22::98:1110:acd3:5d04: [icmp6 sum ok] ICMP6, echo reply, seq 17
    ^C
    2 packets captured
    2 packets received by filter
    0 packets dropped by kernel
    pi@raspberrypi:~ $ sudo tcpdump -i nat64 -nv icmp6
    tcpdump: listening on nat64, link-type RAW (Raw IP), capture size 262144 bytes
    16:03:33.559037 IP6 (hlim 63, next-header ICMPv6 (58) payload length: 16) fd11:22::98:1110:acd3:5d04 > 64:ff9b::808:808: [icmp6 sum ok] ICMP6, echo request, seq 18
    16:03:33.590472 IP6 (class 0x40, hlim 56, next-header ICMPv6 (58) payload length: 16) 64:ff9b::808:808 > fd11:22::98:1110:acd3:5d04: [icmp6 sum ok] ICMP6, echo reply, seq 18
    ^C
    2 packets captured
    2 packets received by filter
    0 packets dropped by kernel
    pi@raspberrypi:~ $ sudo tcpdump -i eth0 -nv icmp6
    tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
    16:04:16.363805 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::18cb:c36e:34de:7939 > ff02::1:ff91:86b9: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::e222:4ff:fe91:86b9
              source link-address option (1), length 8 (1): 00:50:b6:64:09:c3
    16:04:33.365166 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::18cb:c36e:34de:7939 > ff02::1:ff91:86b9: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::e222:4ff:fe91:86b9
              source link-address option (1), length 8 (1): 00:50:b6:64:09:c3
    16:04:49.177597 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:xxxxxxxx: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
    ^C
    3 packets captured
    3 packets received by filter
    0 packets dropped by kernel
    pi@raspberrypi:~ $
    

    I'll try some other examples and see how it goes.

Children
No Data
Related