Hello,
We are currently developing a Zigbee product using nRF Connect SDK v2.8.0. While reviewing the release notes for NCS v2.9.0, we noticed two critical bug fixes related to the ZBOSS stack.
To evaluate whether we should migrate our current project to v2.9.0, we would like to understand the technical details and risks associated with these issues. Could you please provide more information on the following?
1. [KRKNWK-17472] Zigbee devices stops sending/receiving packets when jammed or high wireless traffic is present
-
Root Cause: What is the underlying cause of this issue? Is it a buffer exhaustion, a MAC layer state machine deadlock, or something else?
-
Failure Mode: When the device "stops sending/receiving," does the ZBOSS stack require a hardware reset to recover, or can it recover automatically once the traffic subsides?
-
Reproducibility: Does this occur specifically under 2.4GHz Wi-Fi interference, or is it triggered by a high density of Zigbee packets?
-
Workaround: Is there any known workaround or configuration change available for NCS v2.8.0?
2. [NCSIDB-1410] NWK_addr_req Extended Response issue fix
-
Symptom: What was the specific incorrect behavior in the Extended Response of the
NWK_addr_req? (e.g., missing fields, incorrect status codes, or failure to respond to specific request types?) -
Impact: Does this affect standard device discovery/binding processes or specific Zigbee profiles?
-
Scope: Does this issue primarily affect End Devices, Routers, or the Coordinator?
We are concerned about the stability of our current v2.8.0-based firmware in noisy environments. Any technical insights or internal ticket details you can share would be greatly appreciated.
Best regards,