OpenThread - Pinging Google DNS

[tejaChintalapati]

Hi,

I am trying to connect the Thread Devices to the Internet with the following setup:

1. OTBR from GitHub (This is not Nordic's border router) running on a RPI4 with a NCP(nRF52840-Dongle)
2. A mobile hotspot providing the IPv6 address to the Border-router.

Here are my observations:

1. I did get an IPv6 address on the border-router (2409:xxxx:..........)
2. On the CLI device, on giving "ipaddr" command, I get 4 IP addresses that start with: fd11, fd11, fd80, fd11. I didn't see an IPV6 Address that start with 2xxx:xxxx...... on the CLI device
3. CLI Device "state" is "router"
4. I can ping the border router from the CLI device and I can ping my laptop from the border router(Connected to the same mobile hotspot)

Here are the problems I'm encountering:

1. But, when I try to "ping 64:ff9b::0808:0808", I didn't get any response at all. Not even "Done" or "Timeout"
2. "dns resolve ipv6.google.com" from the CLI device always results in timeout.

I read several answers on this forum and most of them suggesting that the Internet router/ISp didn't provide /62 prefix IPv6 address to the border-router and one answer suggested the "dns resolve" is broken. I am not sure what's causing the issue. Can you please help me understand if it's the problem with the ISP or if this is being caused by the router(mobile hotspot)?

If this is a problem with the ISP, does this mean the OT-BR will never work with that particular ISP? I am happy to share the full IPV6 addresses in a private DM

Thanks for the help.

[Edvin]

Hello,

Have you tried with a router that supports IPv6? Did you do any changes in the application on the nRF?

[tejaChintalapati]

Hi Edvin,

To give you some perspective, I am trying to understand if I can use Thread to build and sell smart home products. I am completely sold on Thread but am stuck with Border Router. I am trying to find answers to the following questions:

1. Does the Border Router need to be connected to a router that supports native IPv6? This will be the biggest bottle-neck because most routers may not support IPv6. And I also read in DevZone that most of them have flawed implementation of the stack.
2. For the border-router to work, does it also need the ISP to support IPv6? How can it get /62 prefix?

Thank in advance. 

[Edvin]

Hello,

I see now that you wrote that you are using a RPi4, and using this, nothing in the thread network is working, is that what you are saying?

What exactly are you running on the RPi4? Where did you find the FW image that is running on it?

Do you have access to an RPi3/RPi3+? Can you test using that instead?

Best regards,

Edvin

[tejaChintalapati]

Hi Edvin,

Thanks for your response. 

Here's the setup:

Observations:

Border Router

• Border router got an IPv6 address that starts with 2409:xxxx.......
• I can ping www.google.com from the border router. This validates that the border router has a working internet connection.

CLI Device

• CLI Device(52840) is connected to the border router successfully. 
• CLI Device(52840) can ping the border router.

Problems:

CLI Device:

• No response to "ping 64:ff9b::0808:0808" command. Not even "Done" or "Timeout"
• "dns resolve ipv6.google.com" from the CLI device always results in timeout.
• CLI Device didn't get an IPv6 address that starts with 2xxx:xxxx..... All 4x IPv6 addresses are starting with fxxx:xxxx.....

Unfortunately, I do not have an RPi3/3+.

Can you help me understand the following?

1. Under what conditions does the the CLI device not receive IPv6 address?
2. In my understanding, please correct me if I am wrong here, a Border router needs a /62 prefix address. Only then can it assign IPv6 addresses to the devices/sensors. Is my understanding right here?
3. If ISP doesn't provide native IPv6 to border router, can the thread devices connect to the internet through the border router? 

Please let me know if anything is not clear. Appreciate your help 

[Edvin]

I am not sure about the details on the differences between the RPi3/Rpi3+ and RPi4. It is not given that the image will run the same on the RPi4. 

Can you please check:

 

Edvin said:

What exactly are you running on the RPi4? Where did you find the FW image that is running on it?

 I don't have an RPi4 (because we don't support it in any of our projects). If I were to order one, and find that it is not working, then there isn't really anything I can do.

Can you try to get hold of an RPi3?

[Edvin]

Ok, I spoke to someone from our Thread team. I'll try to summarize it.

First of all, the Border Router FW that you link to is an external library. 1: I don't know if it works as expected with the Nordic examples. 2: It is also written for the RPi3 HW. Not sure what happens when you try to run it on a RPi4. 

If you want to use the border router FW that we provide, you should check out:

https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/thread_border_router.html?cp=7_3_2_9_0_1#thread_border_router_software

For that, you would also need a RPi3. 

If you decide to go with the BR (Border Router) FW that you linked to, and run into issues, you need to contact the author of that github. We do not support external repos like this one.

Some general IPv4/IPv6 considerations.

1)/2). To get it, the upstream router and border router need to support DHCP-PD (prefix delegation), and the prefix shared by the upstream router needs to be shorter than /64, so the full /64 could be delegated down to the Thread network. I am not sure if the A) DHCP-PD is used, B) Appropriate prefix length is delivered, C) BR is capable of receiving the prefix (in Nordic Border router we use a particular network manager to handle that), D) BR is capable of providing the /64 prefix to the thread network. We use a script to do so in our own BR FW).

3). If ISP doesn't provide native IPv6 to the BR, can the thread devices connect to the internet through the border router?

Yes, but some limitations apply. The most important is that the device will not have it's unique IPv6 globally reachable address. All typical drawbacks of using NAT applies here. The other one is that it will need to use the NAT64 (Network address translation between IPv6 on the Thread network as Thread is purely IPv6, and only the global IPv4 provided by the ISP). So every packet going outside will be translated from the IPv6 to IPv4, and then go through your ISP infrastructure. Of course all external IPv4 traffic sent to the Thread network will be retranslated to IPv6 to reach the thread node.

The OTBR documentation mentions that the NAT64 works if configured as explained here:
https://openthread.io/guides/border-router/access-point#configure-nat

This is one of the benefits of our solution (the BR FW provided by Nordic). This is preconfigured and started automatically. I would gess that the IPv6 connection is not sufficient and that the ISP does not delegate a short prefix using the DHCP-PD. This is sometimes something you would pay extra for, and sometimes not even an option. Therefore you should focus on the IPv4 with NAT64.

[tejaChintalapati]

Wow! I can't thank you enough for providing a crystal clear explaination. Your answer cleared up a lot of questions I had. Thanks a ton for taking time to answer my question.

I think the best course of action is to get a RPi3 and try this setup to see if it works. I shall do that.

One last question that I have is: In future, when we've to move away from RPi, will it be possible to port the Nordic's BR to run on a custom Linux board based on something like AM335x(Beaglebone Black)?

[Edvin]

Hello,

I will forward the appreciation to our Thread team

The border router FW that we provide is based on this repo:

https://github.com/NordicPlayground/nordic-ot-border-router

Unfortunately, there is no guide on how to build it, and I also believe that the NFC Daemon is not publicly available. 

I don't know how to build it, but perhaps if you have some experience with RPis, you understand how they work together? (since there is only links to other repos from this repo). 

Best regards,

Edvin

[tejaChintalapati]

Thanks Edvin for the clarity.

Let me try to get this to work with RPi3+ and fix things as they come.

Thanks again for the help. Your answer cleared a lot of things I have been trying to get answers from.