nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

zb_nwk_neighbor_clear triggers zb_osif_abort upon joining a Zigbee network

Hello,

During my evaluation of nRF52840 I discovered an issue which prevents the device from joining a Zigbee network successfully.

I'm using out of the box zigbee/light_bulb with some logging enabled. When I initiate the network joining on Samsung Smartthings coordinator, ziboss function calls  zb_osif_abort and causes the fatal halt.

I'm using nRF Connect v3.7.1.

Some additional information you might find useful:

* I have a coordinator from other vendor and if I use a dedicated channel used by that coordinator, the light bulb successfully and quickly joins it.

* You can see the call stack on the screenshot below:

* I'm attaching the log messages I see before the device halts.

 

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

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

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

Related