Unable to ping from Thread CLI Example to my PC on IPv4 network

[tak-jp]

Tools in use, etc:

1. nRF5_SDK_for_Thread_and_Zigbee_v1.0.0
2. RaspPi_OT_Border_Router_Demo_v1.0.0-1.alpha
3. NCP example located in <InstallFolder>/examples/thread/ncp/uart/hex/nrf52840_xxaa.hex
4. CLI example located in <InstallFolder>/examples/thread/cli/uart/hex/nrf52840_xxaa.hex
5. nRF52840-PDK
6. Raspberry Pi connect through an Ethernet cable to my switch that provides IPv4 connectivity with the DHCP service.

I'd like to ping from Thread CLI Example to my PC(172.27.131.50), which is on IPv4 network. Referring the Note from this:

---

Note
0808:0808 is in fact the Google DNS server address "8.8.8.8" in hex representation. In that way, you can reach any IPv4 cloud by replacing last 32 bits of an IPv6 address with a correctly encoded IPv4 address.

---

, I run the following command:

1. panid 0xabcd
2. ifconfig up
3. thread start
4. state
5. ping 64:ff9b::ac1b:8332

After running the last command, I don't have any responses. I've logged in RaspPi and pinged toward the PC. This works:

pi@raspberrypi:~ $ ping 172.27.131.50
PING 172.27.131.50 (172.27.131.50) 56(84) bytes of data.
64 bytes from 172.27.131.50: icmp_seq=1 ttl=125 time=0.625 ms
64 bytes from 172.27.131.50: icmp_seq=2 ttl=125 time=0.589 ms

Here is output of ifconfig on the BR:

pi@raspberrypi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.27.197.95  netmask 255.255.255.0  broadcast 172.27.197.255
        inet6 fe80::ba27:ebff:fe47:3d40  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:47:3d:40  txqueuelen 1000  (Ethernet)
        RX packets 3305  bytes 259933 (253.8 KiB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 3877  bytes 567675 (554.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 812  bytes 70895 (69.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 812  bytes 70895 (69.2 KiB)
        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::1cab:d9a6:51c2:4b09  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

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:fe12:6815  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:12:68:15  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1286  bytes 328459 (320.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wpan0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
        inet6 fe80::344c:e80e:4f54:5d47  prefixlen 64  scopeid 0x20<link>
        inet6 fdde:ad00:beef:0:8a9b:2ee2:bc54:fd82  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::fb3d:fd60:2863:bc0  prefixlen 64  scopeid 0x20<link>
        inet6 fd11:22::344c:e80e:4f54:5d47  prefixlen 64  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 6  bytes 964 (964.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@raspberrypi:~ $

Here is output of ipaddr of thread node:

> ipaddr
fdde:ad00:beef:0:0:ff:fe00:5c00
fd11:22:0:0:d621:e3fe:ba6a:4fe2
fdde:ad00:beef:0:2a61:3f7e:5e4e:9eaf
fe80:0:0:0:b872:2c43:c968:25e2
Done

Does anyone know how to fix this?

Thank you.

I've asked similar question before. I think I encounter different behavior. I'm modifying my application (from nRF5_SDK_for_Thread_v0.11.0) to nRF5_SDK_for_Thread_and_Zigbee_v1.0.0 now.

[Piotr Szkotak]

Hello tak-jp,

Thank you for your Interest in the OT Border Router!

Unfortunately the behavoiur you observe is expected.

Acording to the RFC6052 section 3.1 adress translator (tayga deamon performing NAT64 translation on the Border Router) must drop a packet with non-global IPv4 embedded together with well-known prefix (64:ff9b::/96). This is exactly what you observe as 172.27.131.50 is a private IPv4 address.

I can propose two solutions:

1. Change NAT64 prefix in /etc/tayga.conf to be different than 64:ff9b::/96 and use the different one.

2. As your PC can run IPv4 and IPv6 simultaneously (this use case is called dual stack) you could set up the IPv6 network at home even in case you do not have native/global IPv6 connection provided by your ISP. The address you could use is called Unique Local Address (ULA) and is very similar to private IPv4 addresses we are used to. Some routers (e.g. these using openwrt) can let you choose the ULA prefix and use it to address IPv6 enabled devices in the local network. Of course these addresses will not be accessible outside your local network, but would be perfect to experiment with IPv6 and Thread at home.

If you have any more questions regarding the case feel free to ask!

Kind regards,

Piotr Szkotak

[tak-jp]

Hello Piotr,

I understand the reason of the behavior. I've changed NAT64 prefix in /etc/tayga.conf to be different than 64:ff9b::/96 and confirmed that I can ping from Thread CLI Example to my PC.

Thank you for helping me out.