This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Zigbee Association request (ZED) being ACK by coordinator, but ZED leaves anyway

(I am currently trying to learn Zigbee) (Updated entry since I believe I was mis-reading the log and the ZC is ACK and not NACK)

I am currently trying to get my endpoint using the nRF52840 DK to connect to a coordinator, but it seems that my endpoint will give up before the coordinator says okay.

Is there a define that I can set to have my ZED try sending the association request a few times before it tries to leave the network?

Below is the what I see when I use a zigbee sniffer

  1. ZED sends Association Request
  2. ZC Sends ACK
  3. ZED Sends 0x04 (Leave command)
  4. ZC ACK
  5. ZC sends association response (Successful for the prior command)
  6. ZED is still trying to leave the network
  7. ZED times out due (I do not know why it times out)

Below is the log of the sniffer along with the wireshark log.

 Nack.pcapng

Parents
  • Hi Robert,

    Are you using a third party coordinator? Have you checked if coordinator you are using supports Zigbee 3.0? If not I would try enabling legacy mode using zb_bdb_set_legacy_device_support(1) in your project. It seems like there is no TCLK key exchange between the coordinator and your ZED device and that's why the device leaves the network.

    You can compare the sniffer trace using the light_control_coordinator and light_bulb or light_switch example in the SDK to see what you should be expecting.

    Best regards,

    Marjeris

Reply
  • Hi Robert,

    Are you using a third party coordinator? Have you checked if coordinator you are using supports Zigbee 3.0? If not I would try enabling legacy mode using zb_bdb_set_legacy_device_support(1) in your project. It seems like there is no TCLK key exchange between the coordinator and your ZED device and that's why the device leaves the network.

    You can compare the sniffer trace using the light_control_coordinator and light_bulb or light_switch example in the SDK to see what you should be expecting.

    Best regards,

    Marjeris

Children
  • Does that disable the requirement for the TCLK key exchange between the coordinator and the ZED? Or should I use zb_bdb_set_legacy_device_support(0) ?  When calling that function should I also make use of the zb_set_network_ed_role_legacy function instead of the zb_set_network_ed_role to set my role for the ZED?

    I'm currently using the light_switch example as the base line and added the example modules form the multi-sensors example to get some sensors added.  I did remove the light commands and clusters though. Using this as my base line I am trying to connect to a third party coordinator that doesn't support encryption of any kind.

    It does connect and work when I use the coordinator command line interface example as the coordinator and my current modded example. They do perform the TCLK key exchange.

  • Hi Robert,

    Sorry, I found now that there is a bug in the documentation which should be fixed soon. When calling zb_bdb_set_legacy_device_support(1) it will disable the trust center require key exchange (enable legacy Zigbee PRO commissioning) while argument 0 will enable the TCLK key exchange (disable legacy support).

    I think you should also try to call zb_set_network_ed_role_legacy() instead of zb_set_network_ed_role() when initializing the device as well. This will remove the requirement of the TCLK exchange. Unfortunately I don't have a legacy coordinator laying around I can test this with at the moment but I think this should do the trick.

    Best regards,

    Marjeris

Related