Thread Node DNS Resolve inconsistent

[Deepak Gupta]

Hello,

Following is my hardware and firmware setup.

Thread BR:

• PCA10100 v1.0.0  connected over J-Link microUSB port to RPi 3B+   
• SDK v4.1.0

Thread Node:

• PCA10100 v1.0.0
• SDK v4.1.0

I am following the steps as explained here : https://infocenter.nordicsemi.com/topic/sdk_tz_v4.1.0/thread_border_router.html

I am on a IPv4 internet connection. 

The Problem

I am seeing inconsistency in the following step of the webpage

> dns resolve ipv4.google.com fdaa:bb:1::2
> 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=3 hlim=50 time=87ms

The first time the BR and Node are all setup and running the above step works as explained. But thereafter if the BR is restarted (Pi reboot) or power cycled. The DNS resolve and ping fails. (Power cycling the node does not seem to cause this issue)

The thread network seems to be up and running, based on the following

pi@raspberrypi:~ $ sudo wpanctl -I wpan0 scan
   | Joinable | NetworkName        | PAN ID | Ch | XPanID           | HWAddr           | RSSI
---+----------+--------------------+--------+----+------------------+------------------+------
 1 |       NO | "NordicOpenThread" | 0xABCD | 11 | DEAD00BEEF00CAFE | 1616C1D57501C130 |  -33

Following information might also be relevant

pi@raspberrypi:~ $ sudo wpanctl status
wpan0 => [
        "NCP:State" => "associated"
        "Daemon:Enabled" => true
        "NCP:Version" => "OPENTHREAD/20191113-00534-gc6a258e3; NRF52833; Apr  5 2020 21:44:15"
        "Daemon:Version" => "0.08.00d (; Apr 21 2020 19:11:43)"
        "Config:NCP:DriverName" => "spinel"
        "NCP:HardwareAddress" => [F4CE3609868CF9C3]
        "NCP:Channel" => 11
        "Network:NodeType" => "leader"
        "Network:Name" => "NordicOpenThread"
        "Network:XPANID" => 0xDEAD00BEEF00CAFE
        "Network:PANID" => 0xABCD
        "IPv6:LinkLocalAddress" => "fe80::508c:45a0:bf66:baf3"
        "IPv6:MeshLocalAddress" => "fdde:ad00:beef:0:8b70:5f70:360:7bc1"
        "IPv6:MeshLocalPrefix" => "fdde:ad00:beef::/64"
        "com.nestlabs.internal:Network:AllowingJoin" => false
]

I have also noticed that when the DNS resolve is working the CLI command ipaddr shows 4 IPv6 addresses as below. 

5/25/2021 14:53:30.842 [TX] - ipaddr<CR><LF>

5/25/2021 14:53:30.847 [RX] - ipaddr<CR><LF>
fd11:22:0:0:8f2c:9a70:d1a7:bb89<CR><LF>
fdde:ad00:beef:0:0:ff:fe00:2400<CR><LF>
fdde:ad00:beef:0:b129:110f:e9e5:d7b0<CR><LF>
fe80:0:0:0:ecff:550f:3dc5:ab7f<CR><LF>
Done<CR><LF>
> <CR><LF>
>

versus when DNS resolve is not working there are only three IPv6 addresses that are listed. 

5/25/2021 14:55:10.261 [RX] - ipaddr<CR><LF>
fdde:ad00:beef:0:0:ff:fe00:2400<CR><LF>
fdde:ad00:beef:0:b129:110f:e9e5:d7b0<CR><LF>
fe80:0:0:0:ecff:550f:3dc5:ab7f<CR><LF>
Done<CR><LF>
> <CR><LF>
> 

Also once this condition occurs, flashing all the firmware and SD card alone seems to resolve it. 

Look forward to help with this as we are doing a PoC for a large project and this is a crucial step for us. I am willing to provide more information and test any conditions that need to be tested. 

TIA. 

[Charlie]

Hi Deepak,

This ticket discussed a similar issue, it also provides a solution that may be helpful. 

I also strongly suggest you talk with your regional sales manager about your application if you did not, because we are shifting our focus from nRF5 SDK to NCS now, you may get limited support in the future if you still work with the legacy development tools. Our sales experts can provide useful suggestions for your development. You can contact them from this page.

The latest updates about Thread can be found here Thread — nRF Connect SDK 1.5.99 documentation (nordicsemi.com).

Best regards,

Charlie

[Deepak Gupta]

Hi Charlie,

Thanks for the answer and the ticket link. I am trying it out now and if I face any problems I will come back on the same. 

However, does this mean that the condition I am facing is a known condition and the default solution is to reflash the NCP? - Or am I doing something wrong somewhere? 

I am sure to migrate to NCS asap. Currently we are working on a PoC for a client and wanted some Thread demo up and running asap. NCS process and documentation looked more time taking, than the SDK approach. 

Will this issue with NCP reflashing still be there with the NCS and Open Thread Border Router? 

Will the BLE SDKs be migrated to NCS as well? 

Thanks!

[Charlie]

Hi Deepak,

Sorry for the late reply. I spent some time trying to recreate your issue and also compare the official OTBR solution. Here are my replies to your questions.

Deepak Gupta said:

However, does this mean that the condition I am facing is a known condition and the default solution is to reflash the NCP? - Or am I doing something wrong somewhere? 

I did experience a similar issue as your description. It seems when you do a power reset or reboot the program still remembers the former connection, a "sudo wpanctl reset" command will release the connection and create a new one.

Deepak Gupta said:

Will this issue with NCP reflashing still be there with the NCS and Open Thread Border Router? 

The Nordic OTBR you are using is an early release modified from the official OTBR which is maintained by the Openthread development team. After constant updates, the official OTBR provides more futures and a robust process to add or delete devices now. I did not experience a similar issue by far. When you get familiar with wpantund you also would be able to debug this kind of issue. Please turn to the official OTBR suggested by NCS for your development.

Deepak Gupta said:

Will the BLE SDKs be migrated to NCS as well? 

Yes, BLE SDK is also migrating to NCS now.

Best regards,

Charlie