Closed lordldx closed 11 months ago
Hi @lordldx , The log message of the ESP Zigbee SDK will be provided in more detail in the upcoming release version. Joining network failure is a tricky issue, and it is difficult to determine the exact reasons solely based on the aforementioned message. Conducting additional tests may prove helpful in resolving this problem.
The entire Wireshark message associated with the issue serves as a vital resource for us to address the bug effectively.
Could you please attempt to use the Ha_on_off_switch
example as the Zigbee coordinator to establish the network? Additionally, kindly provide us with the Wireshark message captured during the network formation process.
Hi @lordldx ,
Can you try use esp_zb_secur_TC_standard_preconfigure_key_set()
to set the HA_on_off_light
device and keep the same Trust Center standard key in your zigbee network?
The corresponding description for the transport key can be found in Chapter 4.4.2 of the Zigbee specification.
Hi @xieqinan
Creating the network seems to work. See file "create_network-v5.2-dev-1128-g03d4fa2869.pcapng" in the attached zip. Not sure if you'll be able to derive much from it, since the data is encrypted and I'm not sure where I can find the security key for the network the esp32c6 creates. (If you can point me to this, I can also provide you with an unencrypted log)
I also added the wireshark logging of my initial report. See file "join_network_fail-v5.2-dev-1128-g03d4fa2869.pcapng" in the attached zip.
Please let me know how I can assist any further. I'd love to get this fixed!
Hi @lordldx ,
In a general Zigbee network, the security key can typically be obtained from the transport key section.
I am confused about the process of joining a network on your Zigbee network. Firstly, I noticed that the Zigbee coordinator/router sends a transport key packet with a source address of ff:ff:ff:ff:ff:ff:ff:ff to the Zigbee end device. If your Zigbee network is centralized, the specification requires the source address to be the local device address.
f your Zigbee network is distributed, please verify your network using the following guidelines.
So what is your network topology?
Based on the Wireshark log you provided, it seems that your network topology is centralized since only the Zigbee coordinator is distributing the short address (0x0000). However, I am unsure how to explain the presence of the long address (ff:ff:ff:ff:ff:ff:ff:ff). Therefore, we would need more information about your Zigbee network to clarify this.
Besides, it is helpful to tell us whether network security feature is supported in your network Pro? I do not have detect any secuity key section in the wireshark log.
Hi @xieqinan
Thank you for your fast responses and thourough investigation. To answer your questions:
Can you try use esp_zb_secur_TC_standard_preconfigure_key_set()
?
I tried, but I think I'm doing something wrong, because I get even less traffic.
Now the esp32c6 only emits a beacon request and that's it.
I may have misused the function above though, I'm still very uncomfortable with the esp_zb api...
I used it like this:
static void esp_zb_task(void *pvParameters)
{
/* initialize Zigbee stack with Zigbee end-device config */
esp_zb_cfg_t zb_nwk_cfg = ESP_ZB_ZED_CONFIG();
esp_zb_init(&zb_nwk_cfg);
uint8_t key[16] = {0xb6, 0x00, 0x08, 0x56, 0xbe, 0x74, 0x7a, 0xb9, 0xf1, 0x50, 0xed, 0x5f, 0x82, 0x8b, 0x2c, 0xc0};
esp_zb_secur_TC_standard_preconfigure_key_set(&key);
/* set the on-off light device config */
esp_zb_on_off_light_cfg_t light_cfg = ESP_ZB_DEFAULT_ON_OFF_LIGHT_CONFIG();
esp_zb_ep_list_t *esp_zb_on_off_light_ep = esp_zb_on_off_light_ep_create(HA_ESP_LIGHT_ENDPOINT, &light_cfg);
esp_zb_device_register(esp_zb_on_off_light_ep);
esp_zb_device_add_set_attr_value_cb(attr_cb);
esp_zb_set_primary_network_channel_set(ESP_ZB_PRIMARY_CHANNEL_MASK);
ESP_ERROR_CHECK(esp_zb_start(false));
esp_zb_main_loop_iteration();
}
What is your network topology? It's a centralized network. The simplest possible: I have just a ZC which is also an actuator, and then a ZED which is a battery operated button that turns the light on and off. So now I'm just trying to add the esp32c6 as a second ZED.
Is network security feature supported in your network Pro? I actually don't know. The vendor of the ZC I'm using is very scarce with information. I'm using a bticino 3571, which is really just a relay with a Zigbee interface. I bought it in 2019 and it has been discontinued by the manufacturer, so I guess the technology is at least five years old. I tried getting some additional information on how to interface with it from the manufacturer, but I don't get any response. Is there any way I can figure this out from the traffic? From the beacon, or perhaps during initial network creation? I have no problem with completely resetting and reconfiguring the device if this would be any help.
Oh, and I haven't mentioned this before, but it might be important. I'm referencing esp-zigbee-lib v0.6.2, which is higher than the v0.5.0 with which the HA_on_off_light examples is preconfigiured:
## IDF Component Manager Manifest File
dependencies:
espressif/esp-zigbee-lib: "~0.6.2"
espressif/esp-zboss-lib: "~0.4.0"
espressif/led_strip: "~2.0.0"
## Required IDF version
idf:
version: ">=5.0.0"
Hi @lordldx ,
This problem is triggered when the end device receives an unsecured frame on the application support sublayer. According to the specifications 4.4.2.3 section, If the device is operating in the joined and authorized state it may accept a NWK broadcast transport key command with Key type field set to 0x01 (that is, network key) where the message has no APS encryption.
However, the Wireshark log from the Bticino 3571 indicates that the frame is not encrypted, unsafe, and not using the broadcast address.
Therefore, if the coordinator can enable the transport key security feature through programming, the issue can be resolved, and the device will be able to function properly.
Hi @xieqinan
About Section 4.4.2.3 that you quote. It states: "If the device is operating in the joined and authorized state..." I think that is not the case here. I compared the messages in the wireshark log with the sequence diagram in section 4.6.3.1. When the network key is received, the ED (our esp32c6) is still in the "joined but unauthorized" state
This means that, when the transport key is received, the ED should simply move into the "joined and authorized" state, right?
And the esp_zb_app_signal_handler
should be called with signal type ESP_ZB_BDB_SIGNAL_STEERING
Please let me know if there's any flaw in my logic here.
Also: I did some additional research in hopes of finding out more about the bticino 3571. I couldn't find any specifics on their implementation. So, seeing as the source address is set to ff:ff:ff:ff:ff:ff:ff:ff, let's assume that it creates a distributed network for now.
Hi @lordldx ,
From Figure 4-21, we can deduce that the Zigbee end device will remain in the Joined but unauthorized
state upon receiving the association response.
Only when the ZED receives the Network Key, it will transition into the "Join and Authorized" state.
Additionally, the Zigbee R22 certification requires the joining ZED to have the APS security key, and it allows the ZED to join the network without APS security when it is in the Joined and Authorized
state. In other words, if the device has already joined the network, there is no need to perform an exchange of network keys during the next joining process.
Based on this information, I suspect that the "bticino 3571" may not be compliant with the R22 certification, or this bticino 3571
has been pre-configured at the factory to be already eligible for joining its network.
@lordldx please re-open if any follow up comments.
Answers checklist.
IDF version.
v5.2-dev-1128-g03d4fa2869
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP32-C6-DevKitM-1
Power Supply used.
USB
What is the expected behavior?
I expected that the device would join the network.
What is the actual behavior?
The device fails during network steering
Steps to reproduce.
Debug Logs.
More Information.
I sniffed the network traffic (TI CC2531 + ZBOSS sniffer + wireshark) and the join seems to start properly: -> First beacon request and a beacon from the ZC -> Next: Association request from the ZED (my esp32c6), and an association response from the ZC. The response indicates success and assigns a network address to the ZED. -> Next, the ZC transmits the transport key. ZED emits an ACK, but that's it. No more communication from the ZED from then on.
From then on, the whole process repeats every two seconds.
I observed the same behaviour on v5.1-rc2.
When looking at the network steering spec (from the Zigbee BDB spec 2.1, it seems that something goes wrong in Step 9. Looks to me as if the esp32c6 answers "no" to the "Was the network key received succesfully" question. Even though I see it being transmitted and ACKed in the traffic.
I'm honestly a bit disappointed in the amount of logging the zigbee api emits. I've configured Default log verbosity to "Verbose", but the only zigbee related output I'm seeing is the Information logging emited by the HA_on_off_light application code itself. Some lower-level zb or zboss logging would be really helpful here!
I can't seem to attach the pcap file directly in this issue, but here's a screenshot of it. Let me know if you need to see more details: