External ping with border router implementation

[Neal Jackson]

I've successfully built and configured the Openthread border router on a Raspberry Pi according to the instructions in the Readme. I'm using the NRF58240 for my ncp and cli node. I built the ncp application using the correct flags mentioned in the openthread/borderrouter wiki. I've successfully created a network and configured the border router as a "router" and the cli device as a "child". I can ping between the router and cli device using their mesh link local addresses. I'm trying to test external connectivity from the child device through ipv6 pings, but all attempts have been unsuccessful.

From the border router, I'm able to ping outside ipv6 and ipv4 addresses (like Google's DNS server) using the nat64 interface:

    ping 64:ff9b::808:808

I'm unable to do the same on the end device. From Nordic's thread border router documentation, it indicates that pinging from the end device using the NAT64 prefix is possible. My border router is configured with the default NAT64 prefix 64:ff9b::

ifconfig wpan0 is:

    wpan0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  

              inet6 addr: fdde:ad00:beef:0:1ab:b155:d33a:a928/64 Scope:Global

              inet6 addr: fe80::e4cb:98b:8db:5889/64 Scope:Link

              inet6 addr: fe80::7675:f8d7:bffd:f2ec/64 Scope:Link

              UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1280  Metric:1

              RX packets:1 errors:0 dropped:0 overruns:0 frame:0

              TX packets:11 errors:0 dropped:0 overruns:0 carrier:0

              collisions:0 txqueuelen:500 

              RX bytes:56 (56.0 B)  TX bytes:1016 (1016.0 B)

And running ipaddr from the cli end device is:

    fdde:ad00:beef:0:0:ff:fe00:f001

    fdde:ad00:beef:0:7785:e131:bf1:b5ec

    fe80:0:0:0:cca6:6a2d:8965:6067

    Done

How can I set up my Openthread border router and the border agent to properly forward ipv4 traffic as expected?

[Yakun Xu]

Using the scripts provided in border router repo should setup NAT64 automatically.

If that doesn't work, could you please help do the following checks?

1. ping from the child device to some public IPv6 address, and see if it works. This help identify if this problem is caused by NAT64.

2. If the first check pass, check if tayga service is running normally. systemctl status tayga, and try restarting tayga service. systemctl restart tayga.

3. If tayga is OK, could you please share the configuration of tayga and check if forwarding is turned on.

You may also refer to https://github.com/openthread/borderrouter/wiki/NAT64 and see if it helps.

[Neal Jackson]

Hi Yakun,

I am unable to ping a public IPv6 address from the child. I attempted to ping google's IPv6 server (2001:4860:4860::8888) among others.

NAT64 is setup, Tayga is running normally:

● tayga.service - LSB: userspace NAT64

   Loaded: loaded (/etc/init.d/tayga)

   Active: active (running) since Wed 2017-08-09 02:00:19 UTC; 2h 58min ago

  Process: 690 ExecStart=/etc/init.d/tayga start (code=exited, status=0/SUCCESS)

   CGroup: /system.slice/tayga.service

           └─829 /usr/sbin/tayga --pidfile /var/run/tayga.pid

I'm also able to confirm that I'm able to ping IPv4 addresses through the NAT64 prefix setup by tayga from the border router. 

I attached my tayga.conf, but I believe it is the default configuration.
Forwarding is enabled:

cat /proc/sys/net/ipv6/conf/all/forwarding

1

$ cat /proc/sys/net/ipv4/ip_forward

1

Thanks for the help!

[Yakun Xu]

Thanks, it seems the device cannot reach to outside. Did you enabled border router feature when building the firmware, especially for the NCP? If not, could you please try re-building the firmware as follows?

make -f examples/Makefile-nrf52840 BORDER_ROUTER=1 TMF_PROXY=1

[Neal Jackson]

Yes, I used those flags when compiling the firmware on the NCP. I ran "make clean" and rebuilt to make sure, and I am still not able to ping public IPv6 or IPv4 addresses through NAT64.

[Yakun Xu]

Did you remove the whole build directory, for some reason, Makefile-* under examples remembers configurations of the first time. If you wanna changes configure options, the whole build directory should be deleted. We tried to reproduce your problems, but failed. Could you please re-build with the flags I provided before and then, try ping the child from border router to see if raspberry PI can communicate with the child node?

[Neal Jackson]

I compiled with those flags using a freshly cloned repository. I also tested again by deleting the build directory and recompiling. I'm still unable to ping public hosts. I am able to ping between the border router and the child node.

[Xiao Ma]

May I have a question about how to form a Thread Network in your local environment? Using OT-BR web GUI or wpanctl CLI command?

The problem might be there is no on-mesh prefix configured in your thread network. On-mesh prefix should be configured and propagated within the Thread network, otherwise, the child device does not know which border router is responsible for helping forward the ping message outside thread network.

I checked the ipv6 addresses configured in your child device, only mesh-local EID, mesh-local Rloc and link local, no global ipv6 address configured based on the on-mesh prefix.

That would be recommended to use OT-BR web GUI to form a Thread network. The example screenshot like below (notice that on-mesh prefix is also set here). Would you please give it another tryout?

-- 
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/262b5a91-bdec-4006-9d34-5e5380d7780a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Neal Jackson]

Xiaom, thanks for the tip!

I had previously been forming my thread network using the wpanctl on the command line. If I form the network using the we gui, I successfully get an On-Mesh prefix and the child node gets a global IPv6 address. 

From the child I am now able to ping IPv4 addresses using the NAT64 prefix like so:

 

> ping 64:ff9b::acd9:62e

> 

> 8 bytes from 64:ff9b:0:0:0:0:acd9:62e: icmp_seq=4 hlim=50 time=39ms

Sadly, I am still unable to ping public IPv6 addresses. I'm unable to ping Google's IPv6 DNS address (2001:4860:4860::8888) from the child node.

Thanks for all the assistance.

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-users+unsub...@googlegroups.com.

[Xiao Ma]

I captured the ping packet on raspberry Pi with tcpdump, notice that the echo request could be forwarded to the proper interface (e.g. eth0, it has routable ipv6 address) and send it out to Google DNS server (2001:4860:4860::8888).

However, the source ipv6 address is still the global ipv6 address of child device based on on-mesh prefix (e.g. fd11:22:xxx:xxxx::xxxx). Since this address isn’t routable, the echo response cannot reach back to child device properly.

One simple way to address this issue is to configure a NAT between ipv6 address of wpan0 and eth0 interface, when forwarding the echo request, the ipv6 source address will be replaced by eth0’s routable ipv6 address.

sudo ip6tables -A FORWARD -i wpan0 -o eth0 -j ACCEPT

sudo ip6tables -A FORWARD -i eth0 -o wpan0 -j ACCEPT

sudo ip6tables -t nat -A POSTROUTING -o wpan0 -j MASQUERADE

Then you should be able to ping Google DNS server public ipv6 address.

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.

To post to this group, send email to openthre...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/73cf96c5-f8f5-47ac-9b73-91411b3dbf9e%40googlegroups.com.

[Neal Jackson]

Ok, I'll give that a try.

Why isn't the child node given a globally routable IPv6 address by the border router? I'm confused why there needs to be NAT to achieve end-to-end IPv6 connectivity.

To unsubscribe from this group and stop receiving emails from it, send an email to openthread-users+unsubscribe...@googlegroups.com.

To post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/262b5a91-bdec-4006-9d34-5e5380d7780a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-users+unsub...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.

[arquiteturade...@gmail.com]

https://nina-b3-openthread.blogspot.com/2022/03/nina-b302-transmitindo-dados-via-udp.html