This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software: TI-RTOS
My coordinator has rebuild a new network with new NWK Key, but an old joined end-device will scan the parent, and try to rejoin into it. If End-device rejoin failed, it will try to rejoin with unsecured-rejoin. But the coordinator will send a NLME-Leave command to the end-device with new NWK key secured.The end device can't decrypt it.
The Zigbee HA 1.2 End Device will need to recognize a failed unsecure rejoin, timeout, and perform an unsecure join. Please refer to Section 4.7.3 of the 2017 (R22) Zigbee Spec.
Note that backwards compatibility is still intact, with the exception of corner cases including options for joining a new network formed by the original Coordinator acting as the Trust Center. As YK mentioned this presents a security risk. http://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_3_10_00_53/docs/zigbee/html/zigbee/z-stack-overview.html#security
Regards,
Ryan
I have update my SDK to 3.10.01.11, does it supports R22?
If a HA 1.2 End-Device failed rejoin into a z-stack 3.10.01.11 parent, it many change to unsecured-rejoin mode. But z-stack 3.10 parent will refuse any unsecured-rejoin by sending Leave-Req.
The SIMPLELINK-CC13X2-26X2-SDK is a Zigbee r22 Compliant Platform: https://www.zigbee.org/zigbee-compliant-platforms/#zcp/productdetails5/5c8bee17be7b565362682524/
Yes, this is the behavior described in the R22 Zigbee Specification. The HA 1.2 End Device application must change join methods after the unsecured rejoin fails.
Regards,
Ryan
I want my coordinator to accept unsecured-rejoin device and re-transport new NKW key. How can I do to force my coordinator to stop sending Leave-Command to unsecured-rejoin device?
I have provided that set "zgAllowRejoins" to "TRUE", coordinator and router will not send leave-command to unsecured-rejoin child-node. But Trust Center will transport NWK key with Default-Link-Key encrypted. I think that it is better for Trust Center to transport NWK-Key to a unsecured-rejoin node with Verified-Link-Key encrypted.
Part Number: CC2652R
Tool/software: TI-RTOS
In zigbee 3.0 network, a joined Node could get a new Link-Key that is called "verified link key" from trust center. So when the end-device try to rejoin the network by unsecured-rejoin mode, if trust-center had stored its unique Link-key( generated by trust-center). This end device should be accepted by this network.
1, set "zgAllowRejoins" into "TRUE" on router and coordinator, the parent node will not send NLME_Leave command to a unsecured-rejoin end-device.
2, function "ZDSecMgrDeviceJoinDirect" in "zd_sec_mgr.c", there is some issue in it, fix it like this.
ZStatus_t ZDSecMgrDeviceJoinDirect( ZDSecMgrDevice_t* device ) { ZStatus_t status; if(device->secure == FALSE) { //........ } status = ZDSecMgrDeviceJoin( device ); if ( status == ZSuccess ) { //..... #if (ZG_BUILD_COORDINATOR_TYPE) //Add the device as joining device, if it did join unsecured if( (device->secure == FALSE) && !(device->devStatus & DEV_SEC_AUTH_TC_REJOIN_STATUS) )//fixed by luoyiming 2019-07-11 { bdb_TCAddJoiningDevice(NLME_GetShortAddr(),device->extAddr);//don't waiting verify link key for unsecured-rejoin } #endif } //..... }