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

[Bhavit Rajput]

I have created zigbee network using nordic dk board, i am trying to fetch all the active nodes in the network using zdo mgmt_lqi cli and i am getting those details but when i power off any device and then if i fetch the neighbour table i am getting that powered off device too. I have tried to fetch even after 15 minutes but still i am getting that device.

Is there any timeout is defined for this ? or how can i update this neighbour table details?

[Marte Myrvold]

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

[Bhavit Rajput]

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

[Bhavit Rajput]

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.

[Marte Myrvold]

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

[Bhavit Rajput]

nordic2nordic_nwk_log.pcap

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

[Bhavit Rajput]

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.

[Marte Myrvold]

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

[Bhavit Rajput]

Any update regarding this issue? 

[Marte Myrvold]

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

[Marte Myrvold]

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

[Bhavit Rajput]

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

[Marte Myrvold]

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