• State Not Answered
  • Replies 16 replies
  • Subscribers 73 subscribers
  • Views 374 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 341803
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Zigbee end device sending leave command after receiving Transport key command

anusha_14

Hello Nordic support,

My application is a Zigbee coordinator application on nrf52840 based on nRF5 SDK for Thread and Zigbee v4.2.0. I was able to pair a Zigbee end device to this coordinator without any issues. However, I noticed that after a while, the coordinator sent a Transport Key command to this end device even though the end device did not request for key and after this, the Zigbee end device sent a leave command and left the network. 

I have attached the Wireshark Zigbee capture where packet number 14456 shows the Transport Key command sent by coordinator and packet number 14463 shows Zigbee end device sending leave command. 

Encryption key is 72:C1:C3:89:AD:F4:94:46:94:7F:15:51:07:71:DC:93 (Order Reverse) and Global Zigbee alliance Trust Center Link Key 5A 69 67 42 65 65 41 6C 6C 69 61 6E 63 65 30 39 (Order Normal).

I would like to get information on the following points:

1. On what occasions does the coordinator send Transport Key command without Zigbee end device requesting for Key? Is there a way to simulate this behavior to make the Zigbee coordinator send Transport Key command?

2. Why would Zigbee end device send leave command in response to Transport Key command?

Please let me know if you need more details to help in looking into this issue.

Regards,

Anusha


.trv.pcapng

 

Parents
  • 0

    Hi Anusha,

    This may be tricky to get to the bottom of, but I will give it at shot. High traffic in the environment could be a cause for the ZED leaving if the traffic causes interference with ACKs.

    My apologies for such a short reply at this time. I will be back with more before this weekend.

    Best regards,

    Maria

  • 0 in reply to Maria Gilje

    I was not able to find any good answers for you today. I appreciate your patience.

    In the mean time I would like to know your reason for using nRF5 SDK for Thread and Zigbee at this point in time. Is your coordinator an older product?

    I am asking because of the maintenance mode status for nRF5 SDK for Thread and Zigbee.

    Best regards,

    Maria

  • 0 in reply to anusha_14

    Hi Maria,

    I would like to check if you have an update?

    Regards,

    Anusha

  • 0 in reply to anusha_14

    Hi Maria,

    Looking forward to your response.

    Regards,

    Anusha

  • 0 in reply to anusha_14

    Hey Anusha,

    My apologies for the delay.

    anusha_14 said:
    1. Is this behavior expected (i.e as per Zigbee specification)? 

    It is according to specification that the ZED ignores Transport Key messages when it has not requested one and acceptNewUnsolicitedTrustCenterLinkKey is set to false. Are you able to check this policy for the ZED? 

    The relevant part of the BDB Specification v3.0.1 is section 10.2.6.

    anusha_14 said:
    2. Apart from having a less noisy environment, from ZC application point of view, what would you recommend to make this ZED join back without manual intervention?

    My main reason for asking about a less noisy environment is to eliminate noise as a factor. If there are still issues there, we need to do further investigations to find the source of the issue.

    Best regards,

    Maria

  • 0 in reply to Maria Gilje

    Hi Maria,

    Thanks for your response.

    anusha_14 said:

    In this case, from the log, we can see that packet 14341 is an Ack from the coordinator, which means the Verify Key packet was received by coordinator and acknowledged. 

    Then, what could be the possible reason for ZC not sending Confirm Key? 

    1. Could you please provide any possible causes for this to happen?

    Maria Gilje said:
    It is according to specification that the ZED ignores Transport Key messages when it has not requested one and acceptNewUnsolicitedTrustCenterLinkKey is set to false. Are you able to check this policy for the ZED? 

    2. As I am using the ZED from a 3rd party vendor, I will try to see if I can get this information, though it may be difficult. Meanwhile, could you please provide some details on this:

        a. As per zigbee specification, ZED must ignore the transport key message. However, in this case, ZED leaves the network. So, doesn't it mean that ZED is not following zigbee specification?

    Maria Gilje said:
    My main reason for asking about a less noisy environment is to eliminate noise as a factor. If there are still issues there, we need to do further investigations to find the source of the issue.

    3. I am not really convinced that noise may be an issue here since the logs show that ZC is acknowledging the Verify key request. Also, the RSSI of ZED seen by ZC was in the range of -40 dBm before it left the network. Also, another point to note is that this issue was reproduced only once even though we are testing all ZEDs in a noisy environment. Even if noise is a factor here, it should only make ZED go offline from Zigbee network but not make ZED leave the network as noise will always randomly exist in wireless networks. 

    Regards,

    Anusha

  • 0 in reply to anusha_14

    Hi Anusha,

    I have forwarded your questions internally.

    Thank you for your patience.

    Best regards,

    Maria

Reply Children
Related
Terms of service