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.

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

[anusha_14]

Hi Maria,

I would like to check if you have any update.

Regards,

Anusha

[Maria Gilje]

Hey Anusha,

anusha_14 said:

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);?

Your understanding is wrong here. zb_bdb_set_legacy_device_support(ZB_TRUE) will allow both legacy and R21 onwards devices to join the network. The description for the function is ambiguous in the phrasing, but the meaning is that the requirement for key exchange is disabled, not the trust center itself.

anusha_14 said:

 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? 

I got some valuable insights from my colleague today and can answer this properly.

A high traffic network means that most of the air time is occupied, which leads to packets not reaching their destination. This again leads to retransmissions, which are happening a lot in your trace. So a possibility is that the ZC retransmits the Transport Key because the Verify Key (14340) is lost. Since the ZED has already sent a Verify Key it will not send it again, and therefore the ZC will make the ZED leave.

Try to have the devices closer to each other and preferably in a less noisy environment. If there are no issues there, then it is likely that the high traffic is causing packets to get lost.

Best regards,

Maria

[anusha_14]

Hi Maria,

Thanks for your response.

Maria Gilje said:

Your understanding is wrong here. zb_bdb_set_legacy_device_support(ZB_TRUE) will allow both legacy and R21 onwards devices to join the network. The description for the function is ambiguous in the phrasing, but the meaning is that the requirement for key exchange is disabled, not the trust center itself.

This is clear now. 

Maria Gilje said:

A high traffic network means that most of the air time is occupied, which leads to packets not reaching their destination. This again leads to retransmissions, which are happening a lot in your trace. So a possibility is that the ZC retransmits the Transport Key because the Verify Key (14340) is lost. Since the ZED has already sent a Verify Key it will not send it again, and therefore the ZC will make the ZED leave.

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? 

Maria Gilje said:

Since the ZED has already sent a Verify Key it will not send it again, and therefore the ZC will make the ZED leave.

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

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?

Regards,

Anusha

[anusha_14]

Hi Maria,

I would like to check if you have an update?

Regards,

Anusha

[anusha_14]

Hi Maria,

Looking forward to your response.

Regards,

Anusha