• State Answer Suggested
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 57 subscribers
  • Views 1238 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: The relative of ZDSECMGR_TC_DEVICE_MAX recource can not be all release when remove device

user3701862
Prodigy 80 points
Part Number: CC2538

I have 4 devices, a coordinator and 3 routers, and 2 routers have been joined by coordinator. ZDSECMGR_TC_DEVICE_MAX of the coordinator has been set to 2.

And I join the last router to the network. it is fail.

Now If I remove a router first(call ZDP_MgmtLeaveReq()), and then join the last router to network, it fail again.

Should I Need delete any infomation of coordinator by manualy?

  • 0
    Guru 735625 points
    Do you use Ubiqua Protocol Analyzer to check what happens over the air?
  • 0
    Genius 3415 points

    Hi jianf hu,

    If you are sending the frame from the coordinator, the rejoin flag must be set to 0.

    Regards,

  • 0 in reply to YiKai Chen
    Prodigy 80 points

    Thanks YiKai Chen.

    In file ZDSecMgr.c, APSME_TCLinkKeyInit() created APSME_TCLKDevEntry_t items for every
    device,

    Did APSME_TCLKDevEntry_t items should be save the TCLK infomation？

    I wrote follow code after call ZDP_MgmtLeaveReq().

    uint16_t index = APSME_SearchTCLinkKeyEntry(exAddr, &found, NULL);
    if(found == TRUE)
    {
    APSME_TCLKDevEntry_t TCLKDevEntry;
    osal_memset(&TCLKDevEntry, 0x00, sizeof(APSME_TCLKDevEntry_t));
    TCLKDevEntry.keyAttributes = ZG_DEFAULT_KEY;

    osal_nv_write(index, 0, sizeof(APSME_TCLKDevEntry_t), &TCLKDevEntry);
    TCLinkKeyFrmCntr[ZCD_NV_TCLK_TABLE_START - index].txFrmCntr = 0;
    TCLinkKeyFrmCntr[ZCD_NV_TCLK_TABLE_START - index].rxFrmCntr = 0;
    }

    And I test my code, It work.
    Should I need call APSME_EraseICEntry(&TCLKDevEntry.SeedShift_IcIndex), what will it do?

  • 0 in reply to Jose Maria Alvarez
    Prodigy 80 points
    Thanks Jose Maria Alvarez.
    The rejoin was FALSE already.
  • 0 in reply to user3701862
    Genius 3415 points
    Hi jianf hu,

    I don't recommend you to perform that procedure because of for some reason the remote device doesn't leave the network, let say the packet doesn't reach the device you will not have the key to communicate with that device anymore with packets that require APS encryption with the Trust Center Link Key.

    The stack already has a procedure to remove information of devices that are kicked out from the network. If you attach a capture that shows the join fail I'll be able to look further into your issue.

    Regards,
  • 0 in reply to Jose Maria Alvarez
    Prodigy 80 points

    Thanks Jose Maria Alvarez.

    I'm sure device leave success.

    join the last device.psdjoin again after remove one.psd

  • 0 in reply to user3701862
    Genius 3415 points
    Hi jianf hu,

    You cannot be sure of that 100% with all stack vendors that's the reason of my recommendation and beside that since your procedure changes the key management there is a chanse that your implementation will not be compliant with the Zigbee 3 specification anymore.

    From the capture "join again after remove one.psd" the packets where you remove the device are not included. Please share one were you are kicking the device from the network and adding a new one.

    Regards,
  • 0 in reply to Jose Maria Alvarez
    Prodigy 80 points
    Did I missed anything? because it always failed
  • 0 in reply to Jose Maria Alvarez
    Prodigy 80 points
    These procedure is not inculded at this time.
  • 0 in reply to user3701862
    Genius 3415 points

    Hi jianf hu,

    Thanks for the captures. There is no definition in the spec for what happens when the coordinator receives an Update Device command with status 0x02 Device Left like in your capture "removed one.psd". The function that you implemented will be useful to solve your problem but again since the behavior is not defined in the spec now an can be defined in the future there is a chanse that your implementation will not be compliant, just be aware of that.

    There is a function called ZDSecMgrUpdateDeviceInd() in ZDSecMgr.c 

    void ZDSecMgrUpdateDeviceInd( ZDO_UpdateDeviceInd_t* ind )
{
  ZDSecMgrDevice_t device;

  device.nwkAddr    = ind->devAddr;
  device.extAddr    = ind->devExtAddr;
  device.parentAddr = ind->srcAddr;
  device.devStatus  = DEV_SEC_INIT_STATUS;
  device.secure     = FALSE;

  // Trust Center should identify the type of JOIN/REJOIN and
  // Transport the NWK key accordingly, it will only be transported for:
  //              APSME_UD_STANDARD_UNSECURED_JOIN
  //   OR         APSME_UD_STANDARD_TRUST_CENTER_REJOIN
  if ( ind->status != APSME_UD_DEVICE_LEFT )
  {
    if ( ind->status == APSME_UD_STANDARD_SECURED_REJOIN )
    {
      device.devStatus &= ~DEV_SEC_INIT_STATUS;
      device.devStatus |=  DEV_SEC_AUTH_STATUS;
      device.secure = TRUE;
    }
    else
    {
#if (ZG_BUILD_COORDINATOR_TYPE)
      uint8  found;
      uint16 keyNvIndex;
      APSME_TCLKDevEntry_t TCLKDevEntry;
      
      keyNvIndex = APSME_SearchTCLinkKeyEntry(device.extAddr,&found, &TCLKDevEntry);
      
      //If found and it was verified, then allow it to join in a fresh state by erasing the key entry
      if((found == TRUE) && (TCLKDevEntry.keyAttributes == ZG_VERIFIED_KEY))
      {
        TCLKDevEntry.keyAttributes = ZG_DEFAULT_KEY;
        //Increase the shift by one. Validate the maximum shift of the seed which is 15
        TCLKDevEntry.SeedShift_IcIndex++;
        TCLKDevEntry.SeedShift_IcIndex &= 0x0F;
        
        TCLKDevEntry.rxFrmCntr = 0;
        TCLKDevEntry.txFrmCntr = 0;  
        
        //Update the entry
        osal_nv_write(keyNvIndex,0,sizeof(APSME_TCLKDevEntry_t), &TCLKDevEntry );
      }
      
      bdb_TCAddJoiningDevice(device.parentAddr,device.extAddr);
#endif
    
    }

    ZDSecMgrDeviceJoin( &device );
  }

  // PUT YOUR CODE HERE TO REMOVE THE KEY

}

    Is safer to put your code here because you are getting the indication that the device already left the network, this is better that put the code in the leave request.

    I hope this helps,

    Regards,

  • 0 in reply to Jose Maria Alvarez
    Prodigy 80 points

    Thanks Jose Maria Alvarez.

    There is a problem.
    I executed my code at debug mode and put a breakpoint into ZDSecMgrUpdateDeviceInd(). But
    the code is never get to there.

    I register a zdo callback of Mgmt_Leave_rsp, and put my code into the callback, It work
    too.
    Can I use this way to implemented?

  • 0 in reply to user3701862
    Genius 3415 points

    Hi jianf hu,

    I just tested this by myself and I'm getting the breakpoint on ZDSecMgrUpdateDeviceInd() when Update Device is received on coordinator. You need to use this indication to remove the key since this is the confirmation for the device leave in this case.

    Please use a fresh new project and test again, also please provide a new capture of the test.

    Regards

  • 0 in reply to Jose Maria Alvarez
    TI__Guru**** 211947 points
    Hi jianf,

    Did Jose's recommendations resolve your issue? If not then please provide an update.

    Regards,
    Ryan