How to communicate with an end device without security? (TZ-1057)

[Alfff]

Question

I need to communicate, as a coordinator, with a third-party sleepy end device that uses a manufacturer-specific profile. This device does not seem to use network security, and I haven't found a way to disable it on the ESP32H2 either.

Here is a screenshot of the frames exchanged between the third-party end device and the coordinator. You can see that the end device announcement occurs immediately after the association response, without any transport key. I'm just sniffing their frames; there's no ESP32 involved here."

Then, when I try to associate the third party end device with the ESP32, it starts sending "Leave" commands a few seconds after the device announcement. To make matters worse, those "Leave" commands are encrypted using the network key, which the end device does not recognize, so it continues sending commands and data requests:

In this screenshot, you can see the difference between the network layer frame control fields in the coordinator and the end device:

How can I make the ESP32 work with this type of device that does not use security? I tried using esp_zb_secur_link_key_exchange_required_set(false) without any results.

Thank you in advance

Additional context.

No response

[xieqinan]

@Alfff ,

Do you know which Zigbee version the third-party device is using?

[Alfff]

@xieqinan after searching the part numbers in internet, I would say that the third-party device uses Zigbee 2006 stack.

[xieqinan]

Hello @Alfff,

The Zigbee 2006 stack is an older version, while the esp-zigbee-sdk is based on Zigbee 3.0. According to the BDB V3.0.1 specification and the current code implementation of the Zigbee stack, it seems that the esp-zigbee-sdk cannot directly communicate with devices that lack a network key. However, Zigbee 3.0 is backward compatible with Zigbee 2006. More time and research are needed to provide a compatible solution. I will notify you once we have further findings.

[xieqinan]

@Alfff ,

From the above figure, it appears that the third-party (legacy) device is being required to leave when it attempts to send a data request to the coordinator. We can observe that the interval between each data request is 20 seconds, while the ed timeout request process is ignored in the third-party device. I suspect that the long interval between data requests is triggering the end device aging in the coordinator. Could you please add zb_set_ed_timeout(10) before calling esp_zb_start(false) on the coordinator side to verify this idea?

• note: the zb_set_ed_timeout() is defined in #include "zboss_api.h".

Would you mind sharing the complete Wireshark capture that includes the leave command? It would be helpful for us to debug this issue in the future.

[Alfff]

@xieqinan thanks for your support 😊

I'm afraid that aging is not the problem. The default timeout is 256 min. After calling zb_set_ed_timeout(10) it increases to 1024 min. It should be enough for a 20 second period of data request.

I have added this code to esp_zb_buttons_handler:

esp_zb_nwk_info_iterator_t i = 0;
esp_zb_nwk_neighbor_info_t nbr_info;
if (ESP_OK == esp_zb_nwk_get_next_neighbor(&i, &nbr_info)) {
  ESP_EARLY_LOGI(TAG, "short addr: %d. device_type: %d, age: %d, device_timeout: %lu, timeout_counter: %ld", nbr_info.short_addr, nbr_info.device_type, nbr_info.age, nbr_info.device_timeout, nbr_info.timeout_counter);
} else {
  ESP_EARLY_LOGI(TAG, "No neighbor");
}

And this is the result after pressing the button on the evaluation board a few times during the joining process:

I (34336) ESP_ZB_ON_OFF_SWITCH: ZDO signal: NWK Device Associated (0x12), status: ESP_OK
I (34346) ESP_ZB_ON_OFF_SWITCH: ZDO signal: ZDO Device Update (0x30), status: ESP_OK
I (35246) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61438597
I (35716) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61438127
I (36116) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61437727
I (36546) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61437297
I (36966) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61436877
I (37356) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61436487
I (37746) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61436097
I (38186) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61435657
I (38626) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61435217
I (39076) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61434767
I (39506) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61434337
I (39936) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61433907
I (40356) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61433487
I (40776) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61433067
I (41186) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61432657
I (41576) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61432267
I (41976) ESP_ZB_ON_OFF_SWITCH: short addr: 32802. device_type: 2, age: 0, device_timeout: 61440, timeout_counter: 61431867
I (42036) ESP_ZB_ON_OFF_SWITCH: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
I (42396) ESP_ZB_ON_OFF_SWITCH: No neighbor
I (42806) ESP_ZB_ON_OFF_SWITCH: No neighbor
I (43236) ESP_ZB_ON_OFF_SWITCH: No neighbor
I (43656) ESP_ZB_ON_OFF_SWITCH: No neighbor
I (44056) ESP_ZB_ON_OFF_SWITCH: No neighbor
I (44566) ESP_ZB_ON_OFF_SWITCH: No neighbor
I (46526) ESP_ZB_ON_OFF_SWITCH: No neighbor

I attach the Wireshark capture, although is pretty similar to the first one:

It seems that the message I (42036) ESP_ZB_ON_OFF_SWITCH: ZDO signal: NLME Status Indication (0x32), status: ESP_OK is sent before the end devices sends the Data Request which is followed by Leave

[xieqinan]

@Alfff

We have assigned it as the top priority task. We are simulating the situation based on the information provided by you to find a solution. To speed up the process, I hope you can provide the complete logs which can refer to the debug mode docs and Wireshark packet capture from when the third-party device is required to leave. It would also be helpful if you could share the type of third-party device and a purchase link, if possible.

I noticed that the transport key step is not present in the Wireshark capture. Did you modify anything in the ESP_ZB_ON_OFF_SWITCH example?

[Alfff]

@xieqinan thank you for giving high priority to the issue

I have configured the debug mode as shown in the page you provided and this is the output:

I (45844) ESP_ZB_ON_OFF_SWITCH: ZDO signal: NWK Device Associated (0x12), status: ESP_OK
I (45854) ESP_ZB_ON_OFF_SWITCH: ZDO signal: ZDO Device Update (0x30), status: ESP_OK
I (53544) ESP_ZB_ON_OFF_SWITCH: ZDO signal: NLME Status Indication (0x32), status: ESP_OK
ZBOSS: common/zb_address.c:1138   zb_address_delete ref 48
I (60864) ESP_ZB_ON_OFF_SWITCH: ZDO signal: ZDO Device Authorized (0x2f), status: ESP_OK

I attach the .pcapng so you have the full information, use the following network key to decrypt the messages sent from ESP32-H2: D6:7A:CE:45:F4:6A:C1:50:1D:EE:8D:43:92:7D:85:32

wireshark_third_party.zip

I would prefer not to make the device information public. I could give you this information privately if you give me an email or something similar.

Regarding the transport key, I didn't change anything relevant of ESP_ZB_ON_OFF_SWITCH example. If I connect a board with ESP_ZB_ON_OFF_LIGHT example, I can see that command

[chshu]

I think the issue has been resolved. @Alfff feel free to contact us if any further questions.