Thread Border Router v0.10.0: NCP problem

[Reto]

Dear experts,

I've been playing around with Thread since nRF5 SDK for Thread v0.8.0, cloud_coap_client. I use your Border Router example with NCP example running on nRF52840_Preview_DevKit and a RaspberryPi B.

Since I've changed to SDK Thread v0.10.0 with the NCP example of SDK vor Thread v0.10.0 --> my nRF Thread Topology Monitor v0.8.0-1.alpha does not connect to the Boarder Router. As soon as I am switching the NCP of the Border Router back to v0.9.0, everything works fine.

My monitor CLI-Thread-Node, which I am using as monitor, runs the v0.10.0 example (not the v0.9.0). Also the image on the RaspberryPi is from v0.10.0 (I checked, and I saw that the RaspberryPi image of Border Router v0.9.0 is identical to v0.10.0 --> IS THIS MAYBE THE ISSUE?)

I am wondering what the reason is for this behavior? Can you give me any advice what I may did wrong? Or if this is a bug?

Thank you for any hint. Reto

[Reto]

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);

[Reto]

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;
    }
}

[Reto]

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);

[Reto]

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

[Reto]

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