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

[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

[Maria Gilje]

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

[anusha_14]

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

[Maria Gilje]

Hi Anusha,

I have forwarded your questions internally.

Thank you for your patience.

Best regards,

Maria

[anusha_14]

Hi Maria,

Thank you for letting me know. Looking forward to your response.

Regards,

Anusha

[anusha_14]

Hi Susheel,

I notice that this ticket has been assigned to you. Could you please let me know of any update on this ticket?

Regards,

Anusha

[Maria Gilje]

Hi Anusha,

I'm still assigned to this ticket. You probably got notified when I got reassigned this case because of the wait time.

I have not gotten feedback on my internal ticket, only a confirmation that they have received it and will take a look when they are able. Please note that since this issue is for the nRF5 SDK which is deprecated, support on this may take some time.

Best regards,

Maria