Thread Border Router v0.10.0: NCP problem

RE: Thread Border Router v0.10.0: NCP problem

ovrebekk — Mon, 04 Sep 2017 08:31:46 GMT

Hi Reto

Functionally the two are the same, but --chiperase can only be used in combination with the --program command. -e can be used independently.

Best regards

RE: Thread Border Router v0.10.0: NCP problem

Reto — Thu, 31 Aug 2017 16:18:46 GMT

Hi Piotr.

Thanks for your update. It runs now. What I did:

I changed to USB-powered operation of the nRF52840 PDK
I performed "nrfjprog -f -NRF52 -e"
I changed to 1.8V power
I run my custom code which is based on your CoAP cloud example (via Eclipse)

Everything is ok now. Don't know why. I tried a "--chiperase" earlier, it didn't work. What is the difference between "--chiperase" and "-e"? Thank you, Reto

RE: Thread Border Router v0.10.0: NCP problem

Piotr Szkotak — Wed, 16 Aug 2017 07:59:01 GMT

Hi Reto, Thank you for the detailed explanation. I see that you are trying some non default configuration - that way may be harder to isolate the issue. Personally I would start from powering all kits from the debug USB port and set them to be Full Thread Devices. You are right about the usage of the persistent storage, thread network configuration is kept there. There are two ways of cleaning it: "nrfjprog --chiperase" followed by flashing a hex file or without reflashing "factoryreset" CLI command. I would use it on all nodes before further tests, especially on this particular node that does not work at all now.

When it comes to the Extended MAC set to 0 it seems that it is shown for the node that is executing the command as you said. It seems like a minor display bug as the "extaddr" command shows the correct MAC.

I would also make sure that the nRF5x-Command-Line-Tools are in the newest version.

To sum up:

Always perform chiperase before flashing a new firmware.
Try to power from the USB instead of 1.8V
Update nrfjprog.

The next possible steps are using a Thread sniffer or tcpdump on the NCP tunnel interface to see if the DNS request gets there and if it is, if the response is sent.

RE: Thread Border Router v0.10.0: NCP problem

Reto — Sat, 12 Aug 2017 15:41:11 GMT

Sorry for posting so much, but I am confused. I tested it with 3 modules: all of them show "Extended MAC" address = 0000000000 when I execute the CLI on them. Then I tested all 3 modules with Eclipse and my code: 1 runs and I can upload data to the cloud, 2 of them doesn't run (they cannot resolve hostname).

Is it possible that the MAC address of two modules are somehow on a "blacklist" in the Thread Border Router?

Thank you! Reto

RE: Thread Border Router v0.10.0: NCP problem

Reto — Sat, 12 Aug 2017 14:53:37 GMT

My module which shows the problem, has an MAC address of 0000? See here:

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQI In | LQI Out | Age | Extended MAC                                              |
+----+--------+----------+-----------+--------+---------+-----+-----------------                                         -+
| 12 | 0x3000 |       42 |         1 |      3 |       3 |  21 | some MAC address                                          |
| 13 | 0x3400 |       13 |         0 |      0 |       0 |  87 | 0000000000000000                                          |
| 26 | 0x6800 |       42 |         1 |      3 |       3 |   5 | some MAC address                                          |
| 42 | 0xa800 |       12 |         1 |      3 |       3 |   4 | some MAC address                                          |

Done

RE: Thread Border Router v0.10.0: NCP problem

Reto — Sat, 12 Aug 2017 13:14:45 GMT

One more thing: what does work is the command here, which I ran on my CLI Thread node: "dns resolve coap.thethings.io fd00:0064:0123:4567::1". This means that it should be possible resolving the DNS, but somehow this function here is not able to:

error = otDnsClientQuery(p_instance, &query, dns_response_handler, NULL);

RE: Thread Border Router v0.10.0: NCP problem

Reto — Sat, 12 Aug 2017 09:55:01 GMT

Does this make sense to you? I mean: if error is e.g. OT_ERROR_RESPONSE_TIMEOUT, the m_app.state is still changing to APP_STATE_RUNNING. But host name could not be resolved...

Thank you very much!

static void dns_response_handler(void * p_context, const char * p_hostname, otIp6Address * p_address,
                                 uint32_t ttl, otError error)
{
    (void)p_context;

    if (m_app.state != APP_STATE_HOSTNAME_RESOLVING)
    {
        return;
    }

    m_app.state = APP_STATE_RUNNING;

    if (error != OT_ERROR_NONE)
    {
        NRF_LOG_INFO("DNS response error %d.\r\n", error);
        return;
    }

    // Check if its hostname of interest.
    if (p_hostname == m_cloud_hostname && ttl > 0)
    {
        m_app.cloud_address = *p_address;
        m_app.state         = APP_STATE_RUNNING;
    }
}

RE: Thread Border Router v0.10.0: NCP problem

Reto — Sat, 12 Aug 2017 09:53:05 GMT

What I see is that I get this error OT_ERROR_RESPONSE_TIMEOUT when I execute the following function (I see the error OT_ERROR_RESPONSE_TIMEOUT when the function dns_response_handler is called):

otError otDnsClientQuery(otInstance *aInstance, const otDnsQuery *aQuery, otDnsResponseHandler aHandler, void *aContext);

RE: Thread Border Router v0.10.0: NCP problem

Reto — Sat, 12 Aug 2017 08:49:29 GMT

My boards config:

V0.9.1 (monitor)
V0.9.1, V0.9.0 --> trieb both (NCP)
V0.9.0 (COAP clients)

I use ETHERNET, not Wi-Fi on the Raspberry Pi 3 Model B Rev 1.2.

Problem still persists...

RE: Thread Border Router v0.10.0: NCP problem

Reto — Fri, 11 Aug 2017 15:12:52 GMT

Note: I have to add that I changed the device type of my COAP client example to SLEEPY END DEVICE and back to normal device (router). But it doesn't work with either configuration (SED or router). I don't know if this may is a problem?

RE: Thread Border Router v0.10.0: NCP problem

Reto — Fri, 11 Aug 2017 15:08:17 GMT

Is there something written into the non-volatile memory of the Thread nodes around or in the Border Router? I mean, it looks to me like if there is a problem with the routing of the packets from my Thread node to the internet?

Reason to believe this: as I started using a brand new development board, things worked well. But after flashing the 2nd time my FW onto this new board, things stopped working again. Same issue with the:

hostname_resolve(m_app.p_ot_instance, m_cloud_hostname);

Thank you very MUCH!

RE: Thread Border Router v0.10.0: NCP problem

Reto — Fri, 11 Aug 2017 14:43:27 GMT

Hi Piotr,

Yes. The Thread network goes down every time I start the 2nd COAP client
I use RaspberryPi v0.10.0 with NCP 0.10.0 (as you told me I should).
I think the hostname_resolve is executed every time, because I debug it (Eclipse)
The order: I cannot tell if the order is the reason. At the moment, I am not able to connect a particular board, even if it is the only COAP client.
I have the Topology Monitor running all the time (CLI client loaded on a development board).

I run the nRF in the 1.8V mode. Meaning: the switch VEXT--nRF is set to ON and I supply the 1.8V from an external supply. Does maybe the order of power-up (1st nRF 1.8V, then debugging-circuit 5V) make a difference? I observed that it didn't work, and as soon as I connected the USB cable the hostname_resolve() was succesfull. Very strange...

Thank you so much for your support!

RE: Thread Border Router v0.10.0: NCP problem

Piotr Szkotak — Fri, 11 Aug 2017 12:41:55 GMT

Another possible way is debugging the second Cloud COAP Client. You can always start the J-Link RTT Viewer and check logs. Additional ones can be added with the NRF_LOG_INFO() macro. Setting breakpoints would also do. I would focus on the dns_response_handler and hostname_resolve function.

RE: Thread Border Router v0.10.0: NCP problem

Piotr Szkotak — Fri, 11 Aug 2017 12:33:36 GMT

Hi Reto, Thank you for the message.

Is the issue shows up every time you power on the second Cloud COAP Client?
What happens when you use RaspberryPi v0.9.0 image? Is it present as well?
Why do you think this is the hostname_resolve function is executed all the time?
What happens if you power on Cloud COAP Clients in a different order?
Do you have any Thread sniffer available?

With my limited information about your setup I have recreated it on my desk and see no issues after powering the second Cloud COAP Client. Therefore I can see two ways of getting us further towards solving this issue. First is detailed information about the setup: A) Board revision(like v0.8.0/v0.9.0), firmware version for each board(what release has been .hex/.img taken from) B) Steps to reproduce (order in which you power on devices, commands applied and so on)

RE: Thread Border Router v0.10.0: NCP problem

Reto — Fri, 11 Aug 2017 10:27:14 GMT

Hi Piotr I tracked it down a little more in detail. The problem starts when I start the 2nd of two Cloud COAP Clients. Then the border router and all the other Thread nodes start fading away from my Thread Monitoring tool. I think the problem is, that my 2nd Cloud COAP Client executes the function:

hostname_resolve(m_app.p_ot_instance, m_cloud_hostname);

all the time. The 2nd node just don't get the hostname resolved. This seems to break down the whole Thread network.

Do you have any idea on this?

Thank you, Reto

RE: Thread Border Router v0.10.0: NCP problem

Piotr Szkotak — Mon, 07 Aug 2017 07:31:15 GMT

Thank you for update. I don't think that running Cloud COAP example could break anything. Please let me know when you will have more information. If the issue is still there it needs to be sorted out.

RE: Thread Border Router v0.10.0: NCP problem

Reto — Sat, 05 Aug 2017 07:13:10 GMT

Thank you Piotr for your answer and your effort. I tried it several times and it still didn't work for me. Maybe because I have also a Cloud COAP Client example running on the same network? Anyway, I cannot change my NCP to 0.10.0 now, as I am running an long-time test and it works great with 0.9.0. and I don't want to stop it right now. I will give it a try as soon as I've set up my 2nd border router.

RE: Thread Border Router v0.10.0: NCP problem

Piotr Szkotak — Tue, 01 Aug 2017 09:49:28 GMT

Hi Reto, Thank you for your interest in the Thread Border Router. I have tested TTM v0.8.0-1.alpha with SDK and BR v0.10.0 - it seems to work fine. I see all nodes in the TTM and it is possible to connect CLI to the NCP and ping global addresses.

Could you reflash both kits with the v0.10.0 and the --chiperase flag passed to the nrfjprog during flashing (nrfjprog -f NRF52 --chiperase --program _build/nrf52840_xxaa.hex --reset)?

In case the issue is still present please elaborate a bit more on it and attach logs if you think they would help to track the issue. Exact steps to reproduce would be a great hint as well.

I see that the image has been generated with a correct commit, there is also a binary difference between the 0.9.0 and 0.10.0 img files. I wouldn't look for the issue there.

Kind Regards, Piotr Szkotak