Thread border router 1.0.0

RE: Thread border router 1.0.0

Mary — Tue, 03 Jul 2018 16:14:49 GMT

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.

RE: Thread border router 1.0.0

Mary — Mon, 02 Jul 2018 15:53:23 GMT

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
>

RE: Thread border router 1.0.0

Piotr Szkotak — Fri, 22 Jun 2018 08:45:11 GMT

It seems you used:

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

RE: Thread border router 1.0.0

Rob C — Thu, 21 Jun 2018 15:05:25 GMT

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

RE: Thread border router 1.0.0

Mary — Thu, 21 Jun 2018 14:38:50 GMT

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

RE: Thread border router 1.0.0

Mary — Wed, 20 Jun 2018 14:17:08 GMT

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

RE: Thread border router 1.0.0

Piotr Szkotak — Wed, 20 Jun 2018 09:06:09 GMT

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

RE: Thread border router 1.0.0

Mary — Tue, 19 Jun 2018 16:01:32 GMT

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.

RE: Thread border router 1.0.0

Piotr Szkotak — Tue, 19 Jun 2018 15:18:38 GMT

The requirement is that /64 bit prefix needs to be passed to the Thread Network so the SLAAC mechanism is used for the address generation.

I am not aware of any exceptions in that matter.

In theory it should be possible to create additional local IPv6 network for Thread only and perform IPv6 to IPv6 translation (NAT66) to addresses from the global pool. It looks like a huge workaround and the fact that Thread nodes generate randomly their addresses with SLAAC which will not make things easier.

Please note that this is just a theoretical consideration, I am not aware of any attempts taken.

Typical solutions are sticking with NAT64 (with its limitation that the Thread node cannot be reached from the outside world as it does not have a globally reachable address) or contacting Internet Service Provider to provide shorter IPv6 prefix.

Your attempts with do not look good, did you wait after executing ping on the CLI? It can take some time to see any output on the Raspberrys terminal in case of tcpdump.

Is your configuration or image modified anyhow compared to the released versions?

Edit. Regarding your post that appeared when I was writing mine:

Image is configured correctly, paragraph you mentioned is about network equipment used at home or office.

Even if your ISP delegates you prefix that is good enough, lets say /56 the router you connect Raspberry to sometimes delegates /64 to the Raspberry even if it could delegate shorter one.

There are two ways of passing prefix to the next router/device, DHCPv6 is very configurable and can share specified address lengh and SLAAC which operates on fixed /64.

Usually this can be configured in the router panel. Bad news is that many devices provide limited configuration or even do not lack of proper support of these features. From our experience OpenWRT custom firmware provides good support in this regard.

To be honest issues with NAT64 bother me more as this is the configuration that works out of the box in all cases.

I'm wondering if this can be related to your ISP or the AT&T router.

Could you check setup with the different connection? Wi-Fi hotspot shared from the smartphone should be sufficient to check the NAT64.

When all fails also the previous release (0.11.0) can be checked as that border router is completely different since it is based on OpenWRT not the Raspbian.

Kind Regards,

Piotr

RE: Thread border router 1.0.0

Mary — Tue, 19 Jun 2018 15:14:25 GMT

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?

RE: Thread border router 1.0.0

Mary — Tue, 19 Jun 2018 14:03:51 GMT

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?

RE: Thread border router 1.0.0

Mary — Tue, 19 Jun 2018 13:22:17 GMT

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.

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

tcpdump -i eth0 -nv icmp6 or icmp and ping

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

Mary

RE: Thread border router 1.0.0

Piotr Szkotak — Mon, 18 Jun 2018 16:28:26 GMT

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

RE: Thread border router 1.0.0

Mary — Mon, 18 Jun 2018 16:18:01 GMT

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

RE: Thread border router 1.0.0

Mary — Wed, 13 Jun 2018 15:53:06 GMT

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

RE: Thread border router 1.0.0

Mary — Wed, 13 Jun 2018 15:44:23 GMT

Does Commissioning have to be done first?

RE: Thread border router 1.0.0

Mary — Wed, 13 Jun 2018 15:34:24 GMT

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

RE: Thread border router 1.0.0

Piotr Szkotak — Wed, 13 Jun 2018 15:32:40 GMT

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

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

RE: Thread border router 1.0.0

Mary — Wed, 13 Jun 2018 15:20:19 GMT

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?

RE: Thread border router 1.0.0

Piotr Szkotak — Wed, 13 Jun 2018 14:55:54 GMT

OK, just to confirm.

You are able to ping from the CLI address returned by 'sudo wpanctl getprop IPv6:MeshLocalAddress' on the Raspberry, right?

Are you able to 'ping 2600:xxxx:xxxx:xxxx::5c5' from the CLI?

While performing these tests it would be good to sniff a bit on wpan0 and eth0 on the Raspberry.

'sudo tcpdump -i wpan0 ip6' will show you traffic if packets are correctly passed from the NCP to the Raspberry.

It may be worth to reflash all boards with the --chiperase option to make sure that no persistent data stayed on flash as a last resort.

Piotr

RE: Thread border router 1.0.0

Mary — Wed, 13 Jun 2018 13:42:03 GMT

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

RE: Thread border router 1.0.0

Piotr Szkotak — Wed, 13 Jun 2018 13:11:41 GMT

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