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

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