• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 214 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.

CC1352P: Z-Stack Server for Linux - Unsecure Rejoin Policy

Peter Hoyer
Expert 1310 points
Part Number: CC1352P
Other Parts Discussed in Thread: Z-STACK

Z-Stack Linux server "as is" does not support unsecure rejoin which is fine for us. However, we have some quite old plugs with acting as a router in the field which do allow unsecure rejoin.

What happens is that the plug (56C1) will let an end-device (CADF) rejoin insecurely and it will then notify the coordinator:

The coordinator will then send a Remove Device message and the end-device gets lost.

Is there any way to configure the coordinator in a way that itself will not process unsecure rejoins but tolerate Update Device messages from routers even if the end-device has rejoins insecurely?

Regards
Peter

  • 0
    TI__Guru**** 202256 points

    Hi Peter,

    You can follow the ZNP process of APSME_UD_STANDARD_TRUST_CENTER_REJOIN inside ZDSecMgrUpdateDeviceInd, where DEV_SEC_AUTH_TC_REJOIN_STATUS is set before entering ZDSecMgrDeviceJoin.  ZDSecMgrDeviceValidate will return ZSuccess if ZDSecMgrPermitJoiningEnabled and zgSecurePermitJoin are TRUE.  So without modifying the ZNP code, you would need to make sure that permit join is enabled on the ZC when the ZED attempts to join.  The ZDO_MGMT_PERMIT_JOIN_REQ or APP_CNF_BDB_START_COMMISSIONING MT API will help in this regard.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1310 points

    Hi Ryan,

    I was searching in the server code but of course your are right that this is a ZNP firmware issue.

    If I understood you right, one thing that you are suggesting is to enable PERMIT_JOIN when the device tries to do an unsecure rejoin without changing the ZNP code? But this is difficult as I have no idea when a device is going to rejoin.

    But looking at the ZNP code in zd_sec_mgr.c in function ZStatus_t ZDSecMgrDeviceJoin, do I understand the code right that APSME_SearchTCLinkKeyEntry(device->extAddr, &found, &TCLKDevEntry); checks if the device is already known?

    If yes, would it be sufficient to change 

    if( found && (TCLKDevEntry.keyAttributes == ZG_VERIFIED_KEY) )

    into

    if( found )

    and the unsecure rejoin of a known device will be accepted?
    Regards
    Peter
  • +1 in reply to Peter Hoyer
    TI__Guru**** 202256 points

    My mistake Peter, ZDSecMgrDeviceValidate will only be used if DEV_SEC_AUTH_TC_REJOIN_STATUS is not applied.  But my comments regarding ZDSecMgrPermitJoiningEnabled are still valid for this case, just in regards to NLME_PermitJoining instead.  This is behavior caused by the ZNP firmware and it is difficult to ensure that permit joining is enabled if not on forever (not recommended) and unable to modify the behavior of other routing devices in the network.  Thus your solution to force sendNwkKey to TRUE is an option.  You could also change the default zgAllowRejoinsWithWellKnownKey value to TRUE or use MT_APP_CNF_SET_ALLOWREJOIN_TC_POLICY.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Expert 1310 points

    Hi Ryan, I think we will go for the zgAllowRejoinsWithWellKnownKey = true variant. Thank you!