Access Internet and IPv4 network through Border Router

[Mark Sohm]

Hi,

I'm just starting to learn Thread and have created a proof of concept setup.  I have:

1 Raspberry PI running Raspbian and the OpenThread Border Router.  This device is also connect to an IPv4 ethernet.

2 Raspberry PIs running Android Things

Each device is connected to a Nordic nRF52840-PDK.

I went through the OpenThread Border router guide, which worked great.  I did not configure the Soft Access Point on the Border Router, but did perform step 6 Configure NAT as recommended in the WebGUI guide.  "sudo systemctl --failed" shows no failures, so everything should be running.

I have the Android Things LowPan sample, using the Thread network created by the Border Router and the devices are able to see and connect to one another.  Now I'm trying to modify the sample to connect to servers outside the Thread network, but am not able to connect to anything.  

If I try to connect to an internal (non-routable) or public external IPv4 address I get "android.system.ErrnoException: connect failed: ENETUNREACH (Network is unreachable)".  

If I try to connect to a host name (internal or external) I get android.system.GaiException: android_getaddrinfo failed: EAI_NODATA (No address associated with hostname).

From what I've read I think I need to create a NAT to translate between IPv6 thread addresses and the IPv4 addresses on my internal network (connect wpan0 to eth0, but I'm not sure how to do so.  Am I on the right track?  If so, can anyone provide some steps or point me towards a tutorial on how to do this?  Linux networking is new to me so I'm not sure where to start.  Do I need to do anything extra to get DNS on the Thread network, or should this translation take care of that as well?  Thanks!

Mark

[Jonathan Hui]

Thread is an IPv6-only network. As a result, any attempt to communicate using native IPv4 addresses is expected to fail.

OpenThread Border Router supports stateful NAT64 using TAYGA. While that allows Thread devices to communicate with IPv4-only endpoints, the Thread devices are still communicating using IPv6. Using OpenThread Border Router's default configuration, that means constructing an IPv6 address from an IPv4 address using the well-known NAT64 prefix (64:ff9b::/96). For example, 8.8.8.8 -> 64:ff9b::0808:0808.

The other consideration is make sure you have an on-mesh prefix configured with default route enabled on the OpenThread Border Router. This will indicate to Thread devices on the network that the OpenThread Border Router offers a default route.

I admit, I do not have much hands-on experience with Android Things and have not tested this specific scenario AT.

--

Jonathan Hui

--
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/77236588-dc14-4323-a1a4-3508c83e31c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Sohm]

Thanks, this is getting me a bit closer, I didn't know how to construct the IPv6 address from the IPv4 one or that it was required.  I tried that change but still get android.system.ErrnoException: connect failed: ENETUNREACH (Network is unreachable)

Default Route is checked on my border router web GUI.

Should the On-Mesh Prefix I see in the web GUI also be the the well-known NAT64 prefix (64:ff9b::/96)?

Also, this page says: "Configure NAT between the wlan0 (Wi-Fi) and eth0 (Ethernet) interfaces:".    Do I also need to repeat those steps using wpan0 (my NCP) and eth0 to make this work?  I'm not sure how or where the connection between the NCP (wpan0) and ethernet (eth0) is configured .

Mark

[Jonathan Hui]

The on-mesh prefix should be something other than the well-known NAT64 prefix.

I believe the ENETUNREACH indicates that Android Things does not know what interface/next-hop to use. I suspect that somehow the default route configuration coming in from the Thread network isn't making it into the Android Things network stack.

For testing purposes, is there a way for you to manually configure an IPv6 default route via the wpan0 interface in AT?

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/3e0aaeab-007a-4c3e-88f0-5b60842aff40%40googlegroups.com.

[Mark Sohm]

I tried setting up a default route on the AT device initiating the connection, but it doesn't seem to accept IPv6 address.  

First, here are the interfaces I see on the AT device:

adb shell ifconfig

wlan0     Link encap:Ethernet  HWaddr b8:27:eb:70:8d:d3  Driver brcmfmac_sdio

          UP BROADCAST MULTICAST  MTU:1500  Metric:1

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

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

          collisions:0 txqueuelen:1000

          RX bytes:132240 TX bytes:0

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          inet6 addr: ::1/128 Scope: Host

          UP LOOPBACK RUNNING  MTU:65536  Metric:1

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

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

          collisions:0 txqueuelen:1

          RX bytes:2706 TX bytes:2706

wpan1     Link encap:UNSPEC

          inet6 addr: fe80::5820:5e27:2370:4261/64 Scope: Link

          inet6 addr: fd45:5412:9874:0:1c45:1217:d2c3:562e/64 Scope: Global

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1280  Metric:1

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

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

          collisions:0 txqueuelen:500

          RX bytes:0 TX bytes:448

eth0      Link encap:Ethernet  HWaddr b8:27:eb:25:d8:86  Driver smsc95xx

          inet addr:10.42.42.47  Bcast:10.42.42.255  Mask:255.255.255.0

          inet6 addr: fe80::c567:8333:5649:785/64 Scope: Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:11418 errors:0 dropped:5 overruns:0 frame:0

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

          collisions:0 txqueuelen:1000

          RX bytes:1333299 TX bytes:944866

And here are the routes:

adb shell ip r

10.42.42.0/24 dev eth0  proto kernel  scope link  src 10.42.42.47

Nothing with wpan1 listed there, so you are likely onto something...

Then I tried:

adb shell ip -6 route add default 64:ff9b::/96 dev wpan1

AND

adb shell ip -6 route add default 64:ff9b::808:808 dev wpan1

Both fail with the error: Error: either "to" is duplicate, or "64:ff9b::808:808" is a garbage.

Mark

[Jonathan Hui]

Specifying both `default` and `64:ff9b::/96` doesn't seem correct.

Have you tried `ip -6 route add default dev wpan1 metric 1`, following this example?

--

Jonathan Hui

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/df041648-1699-4488-9e07-f74cde3f7843%40googlegroups.com.

[Mark Sohm]

**corrected route list to query ipv6**

It appears Android doesn't allow this:

adb shell ip -6 route add default dev wpan1 metric 1

RTNETLINK answers: Operation not permitted

I thought this may have worked...

adb shell su 0 ip -6 route add default dev wpan1 metric 1

RTNETLINK answers: File exists

But then it's not shown below.  I assume it should be?.

adb shell ip -6 route show dev wpan1

<shows nothing>

Here is my attempted ping from the AT device:

adb shell ping6 -I wpan1 64:ff9b::808:808

connect: Network is unreachable

I did a few more ping6 tests within the network

The Border Router can ping both AT devices (using their thread IPv6 address).

The AT devices cannot ping each other nor can they ping the Border Router's mesh local address.

However, the AT devices can still talk to each other using the Android Things sample (modified so both connect to the Thread network created by the Border Router).

Mark

[Mark Sohm]

Tried a number of things to no avail yet.

I have found that this had an impact when run on the AT device.

adb shell su 0 ip route add table wpan1 64:ff9b::/96 dev wpan1 proto kernel scope link src fd45:5412:9874:0:a859:d2c0:52c6:3d36 metric 1

The error changed from ENETUNREACH (Network is unreachable) to ETIMEDOUT (Connection timed out).

However, in both cases "sudo tcpdump -i wpan0" run on the Border Router doesn't show any activity.

Mark

[Mark Sohm]

I came across this thread https://groups.google.com/forum/#!searchin/openthread-users/dns|sort:date/openthread-users/grrAZFGHpMk/QR6FSS8rCgAJ  that had similar issues to what I'm facing.

In it, it was stated that the NCP firmware should be built with the "TMF_PROXY=1" parameter.  I used the pre-built binary https://openthread.io/guides/ncp/firmware that doesn't have that flag.  

Is that still required?  If so, should that flag be included in the NCP for the client, border router or both?

Mark

[Jeff Bumgardner]

Hi Mark - 

The TMF_PROXY switch no longer exists, OTBR has since been rearchitected and you should use UDP_PROXY instead.  The firmware at https://openthread.io/guides/ncp/firmware#download_nrf52840_firmware_image uses UDP_PROXY, along with the other switches listed there.

The switches required for an OTBR NCP are detailed in the Border Router guide: https://openthread.io/guides/border-router/build#build-and-flash-ncp

The USB=1 switch in the NCP firmware build is used to enable native USB CDC ACM as a serial transport, which is recommended for the nRF52840-PDK vs using the debug port.

To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/be4ee5c6-4fdf-4a00-abcd-44dee1d6ac2e%40googlegroups.com.