zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Sun, 20 Feb 2022 09:13:12 GMT

Hi Marte,

I checked SDK 1.9.0 and, indeed, it's working as expected!

Thank you for the update and sorry for my delayed reply.

Best regards,

Sergey

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Fri, 03 Dec 2021 09:35:30 GMT

Hi Alex,

If you want information about roadmap and releases, please contact our regional sales manager in your area.

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Alex_T — Fri, 03 Dec 2021 07:30:43 GMT

Hi Marte,

When will be the estimated release for this version/fix?

Best regards,

Alex

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Tue, 30 Nov 2021 10:20:33 GMT

Hi Sergey,

This will be fixed in nRF Connect SDK v1.9.0.

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Wed, 03 Nov 2021 12:57:04 GMT

Hi Sergey,

Thank you for the update!

I just tested with v1.7.1, and I am still able to reproduce the issue using the same steps as earlier. Our developers have also reproduces the issue in newer versions of the ZBOSS stack, so the underlying issue is still there. I am not sure why you are not seeing this problem with the QNECT hub anymore, but this information might be useful to our developers in researching the bug.

Unfortunately, I do not have any update on DSR's progress yet.

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Wed, 03 Nov 2021 07:24:38 GMT

Hi Marte,

Just a small update. I tested 1.7.1 and it seems like the LEAVE started working for the hub which supports ZigBee 3.0 - QNECT, but I still have the issue described above with LEAVE on my old Samsung Smartthings.

Best regards,

Sergey

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Sun, 24 Oct 2021 14:49:35 GMT

Hi Marte,

Thank you for the update. I'm happy that you managed to preproduce the issue! I hope that DSR will prioritize it as a critical one and fix it ASAP.

It was my pleasure to help to improve the solution and I'm looking forward to seeing new SDKs with the issue solved.

Best regards,

Sergey

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Thu, 21 Oct 2021 06:43:11 GMT

Hi Sergey,

Our developers were able to reproduce this occasionally on their side. There seem to be multiple issues with respect to the LEAVE command in the newest ZBOSS already. They have reported it as a bug to DSR, and hopefully there will be a fix in a later version of ZBOSS. Thank you for reporting this!

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Wed, 20 Oct 2021 14:07:31 GMT

Hi Sergey,

Thank you for this information! Knowing that the problem appeared first in v1.6.0 will hopefully help narrow it down. I hope you will be able to work with v1.5.1 for now, and I will keep you updated on the progress of this issue.

The cases regarding zb_address_unlock are from the nRF5 SDK for Thread and Zigbee v4.1.0, which use an older version of the stack, ZBOSS v3.3, while nRF Connect SDK use newer versions of the stack, with ZBOSS v3.5.0.0 for nRF Connect SDK v1.5.0 and ZBOSS 3.8.0.1 for nRF Connect SDK v1.7.0. This issue has been solved in the versions of the stack that are in the nRF Connect SDK. Since your issue first appeared in v1.6.0, it seems to be an issue with newer versions of the stack.

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Tue, 19 Oct 2021 15:29:07 GMT

Hi Marte,

I did some experiments with previous nRF Connect SDKs and found out that v1.5.0 and v1.5.1 are working as expected. No halts, when I use zb_bdb_set_legacy_device_support(1) the light bulb can be connected to Samthung Smarthings and disconnected, the same for QNECT, everything works as expected.

SDKs v1.6.0, v1.6.1, v1.7.0 exhibit the issue. Since I've already spent quite some time on trying to identify how I can make it work on the latest SDKs, I'll continue with v1.5.1 for now. But if you need me to try something to validate some possible solution, please, let me know and I'll do whatever is required.

And one more thing, I noticed, although it's not in the call stack (but you can see it on my initial screenshot attached, that the program halts in zb_address_unlock called from zb_nwk_neighbor_clear, and I also found in DevZone that there were several issues related to misbehaving to zb_address_unlock. Maybe my case is somehow related?

Best regards,

Sergey

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Mon, 18 Oct 2021 13:01:48 GMT

Hi Sergey,

If they are on different channels, then interference should not occur, but Zigbee can also be affected by other things, such as interference by Wi-Fi networks on the same channel, as some of the channels of Zigbee and Wi-Fi overlap. Zigbee is expected to be used in environments where there might be a lot of other Zigbee networks and other RF noise, such as being used for home automation in apartment buildings. If the environment is very noisy then it might affect the Zigbee network, so it does not hurt to test in another place. However, I do not think this is related to the issue you are seeing.

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Mon, 18 Oct 2021 11:54:56 GMT

Hi Marte,

Thank you for the update!

I've just come back from my vacation and I'm going to continue investigating from my side too using the Zigbee shell. I've ordered another DK and a hub from a different vendor and I'll try to form a network with them as soon as I get them.

I'll also try to move my experiments to some more RF quiet places because, as I recently discovered, some of my neighbors have some sort of equipment emitting using 802.15.4 (although not on channel 11) and I started thinking maybe it influences my nRF52840 light bulb.

Best regards,

Sergey

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Mon, 18 Oct 2021 09:53:20 GMT

Hi Sergey,

I do not have much of an update, but I just wanted to let you know that this issue is still being investigated. I have not been able to find any solutions or ways to help with this issue, but our developers are looking into it.

As for properties of the leave request, this is something that must be set by the device that sends the leave request. If the rejoin parameter of a leave request is set to true, it means the device that leaves is requested to rejoin the network after leaving it's current parent. So the device will still have the network data stored and will rejoin the network without having to be authenticated again. With this, the device can join the network even if it is closed.

Since you are not able to change the command being sent from the hubs you can try to send a leave command either using another device in the network if you have multiple DKs, or the device can send a leave command to itself. If you have enabled Zigbee shell (set CONFIG_ZIGBEE_SHELL=y in prj.conf) you can send Zigbee shell commands. To send a leave request use the command zdo mgmt_leave. Adding "--rejoin" to the command will set the rejoin flag.

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Mon, 11 Oct 2021 18:18:30 GMT

Hi Marte,

[quote userid="92402" url="~/f/nordic-q-a/80234/zb_nwk_neighbor_clear-triggers-zb_osif_abort-upon-joining-a-zigbee-network/333438#333438"]Is the network open when the device tries to rejoin after successfully leaving, or is it closed so the device is unable to join? Does it halt if you set the "rejoin" flag in the leave request, requesting the device to rejoin?[/quote]

The network is not open when the device is leaving and halting. I can't change any property of the leave request that originates from the hub since I have no access to its code (neither to Samsun Smartthing nor QNECT one). I can change some aspects of handling disconnection in the lightbulb example thought. But, I'm afraid, I need to ask you to provide me with more information about what you would like me to change.

I'm also will be on a short vacation until the end of this week but I'm definitely going to continue my attempts afterward. Please, let me know if you find anything you think could help me with the matter.

Best regards,

Sergey

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Mon, 11 Oct 2021 10:04:13 GMT

Hi Sergey,

I was also unable to find specification for the QNECT hub. However, I see in the sniffer log with the QNECT hub that the Trust Center Link Key is exchanged, so it must be a Zigbee 3.0 device, as legacy devices does not support BDB TC Link Key Exchange. This confirms that the problem is not because of coordinators that are legacy devices, so that is helpful.

[quote user="Sanis"]Indeed, it looks like the device actually leaves the network successfully, tries to rejoin, and then halts. When I switch it off/on, it enters the discovery mode and can join the same network again if I allow that on the hub. [/quote]

Is the network open when the device tries to rejoin after successfully leaving, or is it closed so the device is unable to join? Does it halt if you set the "rejoin" flag in the leave request, requesting the device to rejoin?

[quote user="Sanis"]error code 0x00000004 is returned[/quote]

Is it the function zb_bdb_finding_binding_target or another Zigbee function that is returning error code 4? If so, this error is RET_BUSY, which indicates that the resource is busy and the request cannot be served. When it comes to commissioning, the function that starts the finding and binding procedure, zb_bdb_finding_binding_initiator, checks whether commissioning is in progress or not and returns RET_BUSY if it is, so this might be why. I will look more into this.

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Fri, 08 Oct 2021 19:25:50 GMT

Hi Marte,

Not a problem at all! I'm very interested in solving the issue since I have already invested into a device based on nRF52480 quite some time and want to finish my project. The ICs Nordic is making are truly awesome. But without solving this basic algorithmic issues I can't move any step forward.

QNECT Zigbee hub is very new and, although I couldn't find exact specification, it must use Zigbee 3.0 since the light bulb example connects to the network immediately, without me specifying zb_bdb_set_legacy_device_support(1).

Indeed, it looks like the device actually leaves the network successfully, tries to rejoin, and then halts. When I switch it off/on, it enters the discovery mode and can join the same network again if I allow that on the hub. Here is the value of g_bdb_ctx at the moment of halt.

I forgot to mention, but I found another strangeness in the light_bulb example, and this one is reproducible without any hub. When you provision the firmware (out of the box, no modifications except logs and SEGGER logging backend enabled) and press IDENTIFY_MODE_BUTTON immediately, zb_bdb_finding_binding_target is called (because dev_ctx.identify_attr.identify_time == 0 (ZB_ZCL_IDENTIFY_IDENTIFY_TIME_DEFAULT_VALUE)) and error code 0x00000004 is returned.

Best regards,

Sergey

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Fri, 08 Oct 2021 12:43:45 GMT

Hi Sergey,

Thank you for providing the additional information!

I have still not been able to reproduce your issue using the network coordinator sample as a coordinator, so I am suspecting this might be related to the coordinators. Is the QNECT Zigbee hub also a legacy device (not supporting Zigbee 3.0)?

From looking at the first log, it seems like the device actually left the network and the halt happened after leaving and trying to rejoin, not when trying to join the first time. So the same thing is happening in all three cases, the device leaves the network, tries to rejoin a network without success, and then halts. I have not figured out why the halt happens yet, but I have reported this internally, and our developers are looking into it.

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Fri, 08 Oct 2021 10:01:01 GMT

Hi Marte,

Yes, indeed, I'm using SDK v1.7.0 and just to make sure I re-installed it completely just yesterday before the test.

My DK board is PCA10056 2.0.0 2019.17 683526115.

Best regards,

Sergey

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Fri, 08 Oct 2021 09:13:55 GMT

Hi Sergey,

I am not able to reproduce this on my side. In one of your previous cases you used nRF Connect SDK v1.7.0, so that is what I have been testing with. Could you please confirm if this is the SDK version you are using?

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Thu, 07 Oct 2021 19:01:45 GMT

I discovered that the system triggers a fatal halt after disconnecting from a network even if I don't use Smartthings hub but a hub which supports Zigbee 3.0

Here are the steps to preproduce:

1. Make a project using plain light_bulb example

2. Select channel mask covering default channels, build and upload to the DK

3. Connect DK to the network (in my case it's provided by a QNECT hub)

4. Disconnect from the network

5. Observe the halt

Attaching the pcap, the communication is very clear, only hub and the nRF52840 DKdevzone.nordicsemi.com/.../channel_5F00_11_5F00_halt_5F00_on_5F00_disconnect.pcapng

If I use the channel specific to QNECT hub (channel 11) instead of the mask, the situation, for some reason, is slightly different, I still see the halt with identical stack, but the controller gets reset in a couple of seconds.

Here is the log:

devzone.nordicsemi.com/.../halt_5F00_on_5F00_disconnect.log

I hope this information might help a bit.

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Tue, 05 Oct 2021 14:29:59 GMT

Thank you very much for following up on this case!

I'm looking forward to hearing from you and your team and I believe you'll get to the bottom of the problem.

Brst regards,

Sergey

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Tue, 05 Oct 2021 14:13:02 GMT

Hi,

I have been unable to figure out what the issue might be yet, but I am still looking and will let you know. I have also asked our Zigbee team internally about the Samsung Smartthings hub.

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Tue, 05 Oct 2021 09:31:32 GMT

Hi,

Thank you, I am able to see the packets now. I will look into the sniffer log and come back to you later today.

Best regards,

Marte

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Sergey A. — Tue, 05 Oct 2021 09:20:07 GMT

I believe Smartthings hub uses ZigbeeAlliance09 key

{ 0x5a, 0x69, 0x67, 0x42, 0x65, 0x65, 0x41, 0x6c,0x6c, 0x69, 0x61, 0x6e, 0x63, 0x65, 0x30, 0x39 }

In WireShark:

Security Level: AES-128 Encryption, 32-bit Integrity Protection
Network Key: 39:30:65:63:6E:61:69:6C:6C:41:65:65:42:67:69:5A
(that's the ASCII values of ZigBeeAlliance09 *in reverse*)

I'll double-check when I get to my desk later today.

RE: zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Marte Myrvold — Tue, 05 Oct 2021 09:02:04 GMT

Hi,

I am unable to see the content of the packets as they are encrypted. Could you please either share the network key so I can decrypt the packets, or start the sniffer before the network is started so the sniffer knows the network key?

Best regards,

Marte