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

 

[Maria Gilje]

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

[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

[anusha_14]

Hi Maria,

Thanks for your response. 

High traffic in the environment could be a cause for the ZED leaving if the traffic causes interference with ACKs - In case of high traffic, does it cause the coordinator to send a new Transport key command to end device without the end device sending a key request? In my case, this is what happened and I wanted to check if zigbee end device leaving in case of high traffic is as per zigbee specifications? Is there a way to avoid this from happening from coordinator side? 

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? - Yes, since we started development on our coordinator application few years ago, when nRF Connect SDK was just introduced. 

Additionally, could you please provide information for these specific 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?

Looking forward to more information on this behaviour as it's a bit worrying to see the end device leaving the network and affect our deployed projects. 

Regards,

Anusha

[Maria Gilje]

Hi Anusha,

Short update today, as I have not been able to find any root cause yet.

anusha_14 said:

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?

I can't find any indications in the Zigbee specification that points to any of these behaviours.

One thing I noticed while going through the sniffer trace today is that the coordinator does not send Confirm Key to device 0x89fd after the Verify Key in packet 14340. This may be something to look closer into.

Thank you for your patience.

Best regards,

Maria

[anusha_14]

Hi Maria,

Thanks for this update. I will look into the process of how Confirm Key is sent by Coordinator, which I believe is done by ZBOSS stack itself. From application point of view, in Zigbee handler, note that I have disabled trust center, requiring key exchange by calling this function when signals ZB_BDB_SIGNAL_DEVICE_FIRST_START or  ZB_BDB_SIGNAL_DEVICE_REBOOT is received:

zb_bdb_set_legacy_device_support(ZB_TRUE);

Is there anything that needs to be done from application side to make sure that Coordinator sends Confirm key to zigbee end device?

While looking at some previous Nordic DevZone posts, I found this one:

 Zigbee motion sensor - Child left the network issue 

Could the issue be similar in my case but I have actually set legacy support in coordinator application but the issue still happens?

While looking at zigbee_helpers.c file in zigbee_default_signal_handler function, I found this comment:

Could this be the reason that the end device sent leave request?

Regards,

Anusha

[Maria Gilje]

Hey Anusha,

anusha_14 said:

From application point of view, in Zigbee handler, note that I have disabled trust center, requiring key exchange by calling this function when signals ZB_BDB_SIGNAL_DEVICE_FIRST_START or  ZB_BDB_SIGNAL_DEVICE_REBOOT is received:

zb_bdb_set_legacy_device_support(ZB_TRUE);

The key exchange procedure is only used for Trust Center networks, so what do you mean with key exchange in a distributed security network?

anusha_14 said:

Is there anything that needs to be done from application side to make sure that Coordinator sends Confirm key to zigbee end device?

No, this should be handled by the stack.

anusha_14 said:

While looking at zigbee_helpers.c file in zigbee_default_signal_handler function, I found this comment:

Could this be the reason that the end device sent leave request?

Joining a distributed security network should be supported by the ZED if it follows the specification, so I doubt that that is the actual reason, but a good find nonetheless. It could still be relevant if the ZED does not follow the specification. The relevant section in the BDB specification v3.0.1 is 10.2.1 Joining node policy values. 

Best regards,

Maria

[anusha_14]

Hi Maria,

Thanks for your response.

Maria Gilje said:

The key exchange procedure is only used for Trust Center networks, so what do you mean with key exchange in a distributed security network?

What I meant is, in my application, I am calling this  function zb_bdb_set_legacy_device_support(ZB_TRUE); in Zigbee signal handler for signals ZB_BDB_SIGNAL_DEVICE_FIRST_START 
 

and ZB_BDB_SIGNAL_DEVICE_REBOOT 

From what I understand, disabling trust center means no trust center link key exchange must be done. However, from the Sniffer logs, we see that key exchange is still being done (i.e Request Key, Transport Key, Verify Key as seen in below screenshots).

1. Is this not an issue? Why is coordinator responding to trust center link key exchange procedure even if it is disabled by calling zb_bdb_set_legacy_device_support(ZB_TRUE);?

2. Is there a way for zigbee end device to know that it is joining a Zigbee network that supports legacy network and therefore not send request key command?


Packet 14296 (Request Key)


Packet 14338 (Transport Key):

 

Packet 14340 (Verify Key):

Maria Gilje said:

No, this should be handled by the stack.

Based on the key exchange, is it not Zigbee stack's responsibility to send Confirm Key ? Could you please ask ZBOSS team about this?

Maria Gilje said:

Joining a distributed security network should be supported by the ZED if it follows the specification, so I doubt that that is the actual reason, but a good find nonetheless. It could still be relevant if the ZED does not follow the specification. The relevant section in the BDB specification v3.0.1 is 10.2.1 Joining node policy values. 

Looking at BDB specification in section 10.2.5 flow chart, it is mentioned that zigbee end device must send Node descriptor request. If there is no Node descriptor response received, trust center link key exchange procedure fails. From sniffer logs, I can see that packet 14273 is where the end device has sent this request:

However, even though there is no Node descriptor response, the end device still asks for Request Key (Packet 14296). Could it be because the end device still thinks it is joining a centralized security network? Is there a way for the end device to know that it is joining a distributed security network?

Regards,

Anusha