NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Thu, 21 Oct 2021 12:46:50 GMT

Hi,

I just wanted to update you that in nRF Connect SDK v1.7.0 there is a dedicated API to get active neighbour table entries now, zb_nwk_nbr_iterator_next().

Best regards,

Marte

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Thu, 25 Mar 2021 14:06:45 GMT

Hi,

That you are getting response timeout error makes sense, since it is expecting to get a mgmt_leave_rsp command back. I have asked our developers if they know of any ways to remove the stale entry, so I will come back to you when I hear from them.

Best regards,

Marte

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Bhavit Rajput — Tue, 23 Mar 2021 12:10:23 GMT

I have already tried zdo mgmt_leave command, this command is not working on node which has already left the network, getting response timeout error.

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Tue, 23 Mar 2021 12:03:59 GMT

Hi,

I am not aware of any functions available to the user that delete stale nodes. In the case of end device keep alive, this happens as part of the stack when an end device, using end device keep alive, timeouts, resulting in the parent deleting it.

However, you can try sending a mgmt_leave_req command. This command is used by a local device to request another device to leave the network. I do not know how this will work with a device that has already left, as the device that is requested to leave is supposed to process the request and report back to the local device via the mgmt_leave_rsp command. The easiest way to test this would be to use CLI and send the command zdo mgmt_leave:

zdo mgmt_leave <h:16-bit dst_addr> [h:device_address eui64] [--children] [--rejoin]

You can see examples of how this command is used in the CLI example here. You can also find more information about the mgmt_leave_req command in the Zigbee specification (chapter 2.4.3.3.5 in revision 21 found here), and the zb_zdo_mgmt_leave_req_s struct reference.

I have not tested the mgmt_leave_req command in the case of a stale node myself, so I can not guarantee that it will work. Please let me know if it does not, and I will see if I can find other solutions for this.

As far as I know, it is not possible to force the device to update its neighbor table or routes, so the solution might be to leave and reconnect as you said. If the above solution does not work, I will ask about this internally.

Best regards,

Marte

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Bhavit Rajput — Mon, 22 Mar 2021 11:03:02 GMT

Thanks for the function.

I have used as you mentioned and it is working as you told, so I am getting stale entry but can I delete that node from the stack so neighbor table will get that update?

If above is not possible then when I'll got any stale entry then in order to update neighbor table should that node has to leave and then re-connect the network?

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Thu, 18 Mar 2021 08:36:34 GMT

Hi,

They were referring to the software/protocol stack instead of the hardware/memory region.

To have created a code snippet that you can plug into the zigbee_cli_cmd_zdo.c file, to make things clearer. Afterwards you can read the internal neighbor table through the zdo neighbors command:

/**
 * @brief Prints all entries of the neighbor table.
 *
 * @code
 * zdo neighbors
 * @endcode
 *
 * Example:
 * @code
 * zdo neighbors
 * @endcode
 */
static void cmd_zb_neighbors(nrf_cli_t const * p_cli, size_t argc, char **argv)
{
    uint32_t i;
    zb_ieee_addr_t ieee_addr;
    zb_uint16_t addr;
 
    if ((argc > 1) || (nrf_cli_help_requested(p_cli)))
    {
        print_usage(p_cli, argv[0], "");
        return;
    }
 
    nrf_cli_fprintf(p_cli,
                    NRF_CLI_NORMAL,
                    "\r\n[idx] "
                    "ext_addr         "
                    "short_addr "
                    "type "
                    "sleepy "
                    "lqi "
                    "age "
                    "timeout "
                    "relationship\r\n");
 
    for (i = 0; i < gc_neighbor_table_size; i++)
    {
        if ((gc_neighbor[i].used == 0) ||
            (gc_neighbor[i].ext_neighbor != 0))
        {
            continue;
        }
 
        nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, "[%3u] ", i);
 
        zb_address_ieee_by_ref(ieee_addr, gc_neighbor[i].u.base.addr_ref);
        print_eui64(p_cli, ieee_addr);
 
        zb_address_short_by_ref(&addr, gc_neighbor[i].u.base.addr_ref);
        nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " 0x%04x    ", addr);
 
        switch (gc_neighbor[i].device_type) {
            case ZB_NWK_DEVICE_TYPE_COORDINATOR:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " ZC  ");
                break;
 
            case ZB_NWK_DEVICE_TYPE_ROUTER:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " ZR  ");
                break;
 
            case ZB_NWK_DEVICE_TYPE_ED:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " ZED ");
                break;
 
            default:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " ??? ");
                break;
        }
 
        if (gc_neighbor[i].rx_on_when_idle)
        {
            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " false ");
        }
        else
        {
            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " true  ");
        }
 
        nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " %03u", gc_neighbor[i].lqi);
 
        if (gc_neighbor[i].device_type != ZB_NWK_DEVICE_TYPE_ED)
        {
            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " %03u  ---   ", gc_neighbor[i].u.base.age);
        }
        else
        {
            zb_time_t exp_time = ZB_TIME_SUBTRACT(gc_neighbor[i].u.base.time_to_expire, ZB_TIMER_GET());
            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " --- %07u", ZB_TIME_BEACON_INTERVAL_TO_MSEC(exp_time) / 1000);
        }
 
        switch (gc_neighbor[i].relationship) {
            case 0x00:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " parent");
                break;
 
            case 0x01:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " child");
                break;
 
            case 0x02:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " sibling");
                break;
 
            case 0x03:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " none");
                break;
 
            case 0x04:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " previous child");
                break;
 
            case 0x05:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " unauthenticated child");
                break;
 
            default:
                nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " unknown");
                break;
        }
 
        if ((gc_neighbor[i].device_type != ZB_NWK_DEVICE_TYPE_ED) &&
            (gc_neighbor[i].u.base.outgoing_cost == 0))
        {
            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, " [STALE]\r\n");
        }
        else
        {
            nrf_cli_fprintf(p_cli, NRF_CLI_NORMAL, "\r\n");
        }
    }
 
    print_done(p_cli, ZB_TRUE);
}
...
    NRF_CLI_CMD(neighbors, NULL, "lists all entries from the neighbor table", cmd_zb_neighbors),
    NRF_CLI_SUBCMD_SET_END
};

Example output for an aged-out router (Zigbee coordinator in this case):

> zdo neighbors


[idx] ext_addr         short_addr type sleepy lqi age timeout relationship

[  0] f4ce36aaaaaaaaaa 0x0000     ZC   false  255 003  ---    parent [STALE]

They also tested end device aging. The entry for the end device was simply removed after the timeout.

Best regards,

Marte

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Bhavit Rajput — Tue, 16 Mar 2021 14:56:24 GMT

Thanks for the update.

Can you please explain 1st point, because what I understood from this point is that I can move neighbor table from stack to memory, and then I have to fetch "outgoing_cost" for every node?

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Tue, 16 Mar 2021 13:04:04 GMT

Hi,

I have a few updates from the Zigbee team, which I copied here:

There is no public API to get the "stale"status from the neighbor table. You can try to use the dynamic memory configuration feature, that will move the table from the stack to the application memory and include definitions from zboss_api_internal.h to iterate through it, but this is rather a hack than a solution.
Unfortunately we were unable to find clear statements inside the Zigbee specification, whether stale entries should or should not be included in the MGMT LQI Response. That said, it seems to be valid to include them. Unfortunately - this prevents you from using this responses as the input for applications such as Zigbee topology monitors.
As a potential, future solution, I have asked if it would be valid to change the LQI values to something very low, if the device is marked as stale. Again - I was not able to find something inside the specification, that will require this change inside the stack, but I do see a value in having some sort of indication for external nodes, that the entry has been marked as stale, that's why I proposed it. It has not been decided yet, if it will happen - currently it is being discussed.

Best regards,

Marte

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Bhavit Rajput — Thu, 04 Mar 2021 14:31:00 GMT

Thanks for the update, I'll keep waiting for your further response.

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Thu, 04 Mar 2021 14:19:40 GMT

Hi,

I'm sorry for the late reply, I just want to inform you that we are still working on this.

The Zigbee team confirmed that what is described in the excerpt from the Zigbee specification that I added earlier has happened. After 45 seconds (3*15 seconds) the Outgoing cost in Link Statuses, sent by the coordinator, were set to zero, indicating that this entry is "stale" and may be reused. However, distinguishing between stale and active neighbor table entries is not straightforward, as you must read the outgoing cost of zb_neighbor_tbl_ent_t, and there is no public API to get those, but they are instead a part of the stack. However, our Zigbee team will keep working on this and try to find a solution. I will keep you updated when I hear more from them.

Best regards,

Marte

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Wed, 10 Feb 2021 14:49:33 GMT

Hi,

I'm afraid I haven't heard back from the Zigbee team yet, as they have a lot to do right now. I'll let you know as soon as I hear from them.

Best regards,

Marte

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Bhavit Rajput — Tue, 09 Feb 2021 12:54:48 GMT

Any update regarding this issue?

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Tue, 02 Feb 2021 08:19:25 GMT

Hi,

I see that the last Link Status from your router is packet 45. After that it stops sending, and the only Link Status messages sent are by the coordinator (source address 0x0000 indicates that the coordinator is sending the packet). Since the router stops sending Link Status, it should be removed from the neighbor table of the coordinator. I'm not sure why that doesn't happen, but I've asked the Zigbee team internally and will come back to you when I get a response from them.

Best regards,

Marte

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Bhavit Rajput — Tue, 02 Feb 2021 06:20:29 GMT

In this sniffer log after frame No. 46, I have turned of nordic router but in the Link status you can see 1 link which is indicating that router.

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Bhavit Rajput — Mon, 01 Feb 2021 11:51:35 GMT

devzone.nordicsemi.com/.../nordic2nordic_5F00_nwk_5F00_log.pcap

Kindly find the attached sniffer log of Nordic coordinator and router.

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Fri, 29 Jan 2021 15:11:11 GMT

Hi,

You're correct that the router should've been removed from the neighbor table in that case, according to what's stated in the specification. I will ask internally about this and come back to you.

In the mean time, could you collect a sniffer log and check for link status packets from your router? Please make sure to start the sniffer before the network is created, to avoid that the payload is encrypted. In order to filter for link status you can use the following filter in Wireshark: "zbee_nwk.cmd.id == 0x08". You can also attach the sniffer log here as a pcap file so that I can look at it.

Best regards,

Marte

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Bhavit Rajput — Fri, 29 Jan 2021 11:55:50 GMT

Ok I understood your point, but can you explain why am I getting following behavior?

I have configured 1 Nordic Dk as Coordinator and 2nd as router, so when router is ON and I fetch neighbor table of coordinator then I got table with datils of router which is working fine, but my problem is when I turned off router and then fetch the table then again I am getting that router's detail in table, even after 15 minute I am getting that router in the table.

My question is why am I getting that turned off router's details? it should be gone from the neighbor table details, that is not happening.

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Thu, 28 Jan 2021 12:39:10 GMT

Hi,

This will not work for the router, as it doesn't have the availability for the same keep alive functionality as the end device does. However, this should be handled by default by the Zigbee stack.

This is done by using link status command in order to keep track of route symmetry. Every so often a router will send out a broadcast with a radius of 1. This broadcast indicates the link status, and the neighboring routers will keep track of these messages to determine which routers can hear them, and which they can hear in return.

You can also find more information about neighbor tables and this in the Zigbee specification, in chapter 3.6.1.5:

For devices using link status messages, the age fields for routers in the neighbor table are incremented every nwkLinkStatusPeriod. If the value exceeds nwkRouterAgeLimit, the outgoing cost field of the neighbor table entry is set to 0. In other words, if a device fails to receive nwkRouterAgeLimit link status messages from a router neighbor in a row, the old outgoing cost information is discarded. In this case, the neighbor entry is considered stale and may be reused if necessary to make room for a new neighbor. End devices do not issue link status messages and therefore should never be considered stale.

In the SDK, the number of missed link status command frames before resetting the link costs to zero (nwkRouterAgeLimit in the Zigbee spec) is defined by ZB_NWK_ROUTER_AGE_LIMIT, and the time in seconds between link status command frames (nwkLinkStatusPeriod in the Zigbee spec) is defined by ZB_NWK_LINK_STATUS_PERIOD. These are by default 3 and 0xf, but they can be changed.

Best regards,

Marte

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Bhavit Rajput — Thu, 28 Jan 2021 04:44:23 GMT

Can you please confirm ? Is it going to work with router too?

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Bhavit Rajput — Fri, 22 Jan 2021 13:07:39 GMT

Ok, this will work for end device but what for Router, will it work for Router too?

RE: NRF52840 zigbee router's neighbour table (management lqi) is not updating even if the end device is disconnected

Marte Myrvold — Fri, 22 Jan 2021 13:03:44 GMT

Hi,

If you're using end device keep alive, then the router parent should delete a child from it's neighbor table if it doesn't receive a keep alive message during the timeout period. The end device timeout period can be configured with zb_set_ed_timeout, and how often the keep alive message is sent can be configured by zb_set_keepalive_timeout. Please note that you should set this period in such a way that the end device sends at least 3 keep alive messages during the end device timeout period. You can read more about end device keep alive here. There are also several examples that use this that you can take a look at to see how it's used, like the light control example, where you can find it at line 534 in main.c in the light switch code in v4.1.0 of the SDK.

Best regards,

Marte