zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Hi,

Is the Samsung Smartthings coordinator Zigbee 3.0 compatible, or is it a legacy device? Please try calling zb_bdb_set_legacy_device_support(1) on the light bulb after ZBOSS is initialized, for example in ZB_BDB_SIGNAL_DEVICE_FIRST_START or ZB_BDB_SIGNAL_DEVICE_REBOOT. This will enable support for legacy devices.

If this does not solve the issue, can you get a sniffer log of this behavior and upload it here as a pcap file?

Best regards,

Marte

Hi Marte,

Thank you for your quick feedback and the suggested fix!

As you suspected, Samsung Smartthings hub I'm using does not support Zigbee 3.0.

So I tried to add zb_bdb_set_legacy_device_support(1) call and, indeed, the light bulb was successfully found by the hub and joined the network. But when I tried to remove it from the network, the same halt with identical call stack was triggered (zb_nlme_network_discovery_confirm -> zb_nwk_neighbor_clear -> zb_osif_abort).

I'm attaching the sniffer log you asked. It should contain all the moments from joining the network, toggling on/off, and, finally, leaving which ended up in the halt.

The log might be a bit polluted with communications with other network devices I've got connected, but if you need a clear one, just the hub and the light bulb example, please let me know and I'll try to produce one. 

Best regards,

Sergey

Log

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

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.

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

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

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

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

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 DK

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:

I hope this information might help a bit.

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

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

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