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.

CC2538-CC2592EMK: How to change the end device rejoin default as insecure rejoin?

Part Number: CC2538-CC2592EMK
Other Parts Discussed in Thread: CC2538, Z-STACK

Dear all,

    I learnt the secure rejoin and insecure rejoin in the link (https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/701530/cc2538-rejoin-policy-in-zigbee-3-0-1 ).

     If I want to test the insecure rejoin in two CC2538 boards, I need to change

     (1) the controller setting (removing device validation from ZDSecMgrDeviceJoin)

     (2) the end device setting (Z-Stack currently processes rejoins as such: 1. Secure 1 channel 2.Secure all channels 3. Unsecure 1 channel 4. Unsecure all channels continuously.)

      Right?

     The question now is that I cannot find the settings of the end device, can I modify this part manually? If so, where is the settings? somewhere in bdb.c or other files?

    Best Regards

  • Hi Xian,

    Have you tried setting SECURE=0 in the predefined settings?  I imagine you are looking for a TC rejoin as would be handled by NLME_ReJoinRequestUnsecure in bdb_rejoinNwk.

    Regards,
    Ryan

  • Dear Ryan,

         Thank you Ryan, I got it.

         SECURE=0 in predefined settings is unencrypted communication.

         NLME_ReJoinRequestUnsecure is what I want.

         Best Regards

  • Dear Ryan,

         I got a new problem with this insecure rejoin test.

         When I let the end device do the insecure rejoin, the controller with let the end device to leave the network. Every time it will end up with leave packet.

         Is there any solution? What is the problem of this problem?

         Best Regards

  • Do you have permit join enabled on the ZC?  Have you further debugged inside IAR to determine the reason behind the Leave Request, or modified ZDSecMgrDeviceJoin as suggested in the prior E2E question?

    Regards,
    Ryan

  • I modified ZDSecMgrDeviceJoin by commenting the following lines,

    ZStatus_t ZDSecMgrDeviceJoin( ZDSecMgrDevice_t* device )
    {
    ZStatus_t status = ZSuccess;
    uint16 ami;

    // attempt to validate device that joined/rejoined without security
    // if ( device->secure == FALSE )
    // {
    // status = ZDSecMgrDeviceValidate( device );
    // }

    Is this what you mean?

    Besides, what do you mean by (1) have permit join enabled on the ZC or (2) further debugged inside IAR to determine the reason behind the Leave Request?

    What I did was to test the following lines (in ZStatus_t bdb_rejoinNwk(void) in bdb.c),

    // Perform Secure or Unsecure Rejoin depending on available configuration
    if ( ZG_SECURE_ENABLED && ( ZDApp_RestoreNwkKey( TRUE ) == TRUE ) )
    {
    // rejoinStatus = NLME_ReJoinRequest( ZDO_UseExtendedPANID, _NIB.nwkLogicalChannel);
    rejoinStatus = NLME_ReJoinRequestUnsecure( ZDO_UseExtendedPANID, _NIB.nwkLogicalChannel);
    }
    else
    {
    rejoinStatus = NLME_ReJoinRequestUnsecure( ZDO_UseExtendedPANID, _NIB.nwkLogicalChannel);
    }

    When I did NLME_ReJoinRequest, it was fine.

    When I did NLME_ReJoinRequestUnsecure, it showed leave as following

    How to check permit join?

    How to further debug inside IAR? I tried to read NLME_ReJoinRequestUnsecure, but cannot.

  • Permit join is the time the network is open for joining during commissioning, set by BDBC_MIN_COMMISSIONING_TIME when BDB_COMMISSIONING_NWK_STEERING is set in the BDB or the ZDSecMgrPermitJoining function is called.  It has to be enabled during the time the device attempts an unsecure rejoin.

    Debugging in IAR means setting a breakpoint in the ZC's ZDSecMgrDeviceJoin function and stepping through how it processes ZDSecMgrDeviceValidate -> ZDSecMgrDeviceValidateRM, and monitor whether ZFailure is ever returned instead of ZSuccess.  These functions further prove the importance of having ZDSecMgrPermitJoiningEnabled equal to TRUE.

    Regards,
    Ryan

  • I just set the break points and stepping through to check the packets in Ubiqua. I found that in inscure rejoin, the leave packets send after
    if (zdoCBFunc[ZDO_TC_DEVICE_CBID] != NULL ) 
    This problem only happens in insecure rejoin process, what is the problem here? Any solution?

  • It appears that ZDSecMgrDeviceJoin completed successfully, since zdoCBFunc[ZDO_TC_DEVICE_CBID] is typically only necessary for higher layer function passing like for MT used with the ZNP.  If ZSuccess is passed back to ZDSecMgrDeviceJoinDirect then you should further step debug to find out what other function fails.  The goal is to determine where NLME_LeaveReq is referenced, if not ZDSecMgrDeviceRemove then it resides in the pre-built Z-Stack library as alluded in the original question E2E thread.

    Regards,
    Ryan

  • I repeat the stepping through and find that the the ZDSecMgrDeviceJoinDirect can finish, and then through ZDSecMgrDeviceNew, ZDSecMgrNewDeviceEvent, (activeTaskID = TASK_NO_TASK;)osal_run_system, there is no leave packet until this point.
    Does this mean that the new join event finish? If so, the leave packet is not from the new device join event, right?

    I recheck the insecure rejoin and secure rejoin process again in Ubiqua, find the difference is that when the end device send End device Timeout request, secure rejoin send End Device Timeout response, insecure rejoin send Leave.
    Where does the coordinator process this End device Timeout request? Is there any specific function pointed at End device Timeout request processing? 

  • NLME_LeaveReq could be called by the device association processing inside the network layer, please set zgAllowRejoins to TRUE for the ZC and let me know whether this affects behavior.

    Regards,
    Ryan

  • There is still leave packet in the end, but there is End device Timeout Response packet and some functional packets can send and receive between the controller and end device.

  • If the Leave Request now occurs about five seconds after association and there is no TCLK Update Request, you will need to make sure that BDB_DEFAULT_TC_REQUIRE_KEY_EXCHANGE on the ZC is FALSE.

    Regards,
    Ryan

  • No problem now, thank you very much.