CC2652R: Request key is not answered from ZC

Hamza Kadhum

Part Number: CC2652R

Hi,

I have decided not to transport any key to the joining devices because i have preconfigured the keys. The transport key function on the coordinator ZDSecMgrSendNwkKey is not called because I dont need to transport key, but then the coordinator refuses to respond to request key. The reason why it does not respond is in the ZDSecMgrTclkReq function, where found returns 0.

APSME_SearchTCLinkKeyEntry(initExtAddr,&found, &TCLKDevEntry);

//If found, generate the key accordingly to the key attribute
if(found)
{
//Generate key from the seed, which would be the unique key
ZDSecMgrGenerateKeyFromSeed(TCLKDevEntry.extAddr,TCLKDevEntry.SeedShift_IcIndex,req.key);

// always secure
req.nwkSecure = TRUE;
req.apsSecure = TRUE;
req.tunnel = NULL;

// send key to initiator device
req.dstAddr = ind->srcAddr;
req.extAddr = initExtAddr;
req.initiator = TRUE;
req.keyType = KEY_TYPE_TC_LINK;

APSME_TransportKeyReq( &req );

// clear copy of key in RAM
memset( key, 0x00, SEC_KEY_LEN);

}

But if I change so that I am transporting key of 0s, just using the SendNwkKey, the ZDSecMgrTclkReq respond to request key and found is equal to 1.

using CC2652R zc and zed.
What is the reason behind this?

Regards,
Hamza

over 4 years ago

0 Ryan Brown1 over 4 years ago

TI__Guru**** 202106 points

Hey Hamza,

Does the ZED send a Device Announce after the successful Association Response and does it request the TCLK with the correct NWK key? Make sure that the ZC's ZDSecMgrDeviceJoin correctly adds the device to the address manager (ZDSecMgrAddrStore) and does not clear or remove it (ZDSecMgrAddrClear or ZDSecMgrDeviceRemove) based on the absence of ZDSecMgrSendNwkKey. You need to make sure that ZCD_NV_EX_TCLK_TABLE has been updated with some entry for the ZED. Please provide a small sniffer log of joining and the key update request if possible.

You may want to align with Michael Henriksson: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/892385

Regards,
Ryan

0 Hamza Kadhum over 4 years ago in reply to Ryan Brown1

Intellectual 945 points

Hi Ryan,

The ZDSecMgrSendNwkKey returns either Zsuccess or failure. The ZDSecMgrDeviceJoin is then continued only if status is ZSuccess, it never goes to ZDSecMgrAddClear or ZDSecMgrDeviceRemove.

The data request continues and after 5 tries it request key again and does not get any response from coordinator. NWK is the same and all communication is received on Coordinator.

It only works if i send a nwk key of 0s or any random value. I don't want to do transport key command because it seems unnecessary now that all network keys are pre-configured.

Best regards,

Hamza

0 Ryan Brown1 over 4 years ago in reply to Hamza Kadhum

TI__Guru**** 202106 points

Hi Hamza,

Thank you for clarifying. Are you sure that ZDSecMgrSendNwkKey from ZDSecMgrDeviceJoin is the only API removed from your ZC, and what other changes are there? I do not see anything in ZDSecMgrSendNwkKey that creates a TCLKDevEntry to later be found by APSME_SearchTCLinkKeyEntry. Have you tried keeping ZDSecMgrSendNwkKey but only removing APSME_TransportKeyReq? Have you considered initializing the entry since it is not found? There is an example of this in APSME_TCLinkKeyLoad.

Regards,
Ryan

0 Hamza Kadhum over 4 years ago in reply to Ryan Brown1

Intellectual 945 points

Hi Ryan,

Thank you for your help, it worked.

I looked through APSME_TCLinkKeyLoad and added the code where it does the entry in the function where it send the network key. But to synchronize their protocol, I made sure that the request key function from ZED was a bit delayed so that the ZC could register the entry. Another solution would be to have the entry before send nwk key function, but this current solution seems more reasonable.

Best regards,
Hamza

0 Hamza Kadhum over 4 years ago in reply to Hamza Kadhum

Intellectual 945 points

Hi again Ryan,

So I just identified another problem regarding rejoining process. The ZED rejoin is not allowed and is indicated to leave. Through debugging i saw that in ZDSecMgrDeviceJoinDirect the device is inserted to ZDSecMgrDeviceJoin and from there is removed. All this is dependent on two variables, device->secure = FALSE and device->devStatus & DEV_SEC_AUTH_TC_REJOIN_STATUS

The end device joining has device->secure = TRUE, and devstatus 0x6C which is missing identifier.

What is meaning of device->secure and devStatus? How does it affect the protocol if I allow for device secure = TRUE?

See following packet sniffer;

Best regards,
Hamza

0 Ryan Brown1 over 4 years ago in reply to Hamza Kadhum

TI__Guru**** 202106 points

Hi Hamza,

You are making good progress to overcome the roadblocks that occurred from removing an assumed step in the joining process. The following are the bit values for devstatus:

// Bitmap of associated devices status fields
#define DEV_LINK_STATUS     0x01           // link is in-active ?
#define DEV_LINK_REPAIR     0x02           // link repair in progress ?
#define DEV_SEC_INIT_STATUS 0x04           // security init
#define DEV_SEC_AUTH_STATUS 0x08           // security authenticated
#define DEV_SEC_AUTH_TC_REJOIN_STATUS 0x10 // Assume secure device that performs TC rejoin

#define DEV_SECURED_JOIN    0x20 // Device joined secure
#define DEV_REJOIN_STATUS   0x40 // Device rejoined
#define DEV_HIGH_SEC_STATUS 0x80 // Device joined as High Security

0x6C is 01101100b, therefore DEV_SEC_INIT_STATUS, DEV_SEC_AUTH_STATUS, DEV_SECURED_JOIN, and DEV_REJOIN_STATUS are set but DEV_SEC_AUTH_TC_REJOIN_STATUS is not. The secure bit indicates whether the device already has NWK security information which should be TRUE in your case. The rejoining ZED should not have the DEV_SEC_AUTH_TC_REJOIN_STATUS so you will need to further debug the ZC to find out why the device is asked to leave. Can you please provide the details of the Rejoin Request/Response and Leave Request?

Regards,
Ryan

0 Hamza Kadhum over 4 years ago in reply to Ryan Brown1

Intellectual 945 points

Hi Ryan,

Thank you for the clarification.

I am currently debugging it. I have attached the Rejoin request/response and leave request.

Rejoin Request

Rejoin response (ignore the marked packet).

Leave request

Best regards,
Hamza

0 Ryan Brown1 over 4 years ago in reply to Hamza Kadhum

TI__Guru**** 202106 points

There is nothing out of the ordinary with the packets, the Leave with Rejoin may indicate that the ZC has not added the ZED to its association table.

Regards,
Ryan

0 Hamza Kadhum over 4 years ago in reply to Ryan Brown1

Intellectual 945 points

Hi Ryan,

I agree. Is the association table ZDSecMgrAssocDeviceAuth?

Im currently looking at ZDSecMgrNewDeviceEvent where it sets device secure = True because of rejoin...But again, it is in ZDSecMgrDeviceJoin where it checks if device secure, now because device secure is set to True in functions before, the if statement is not executed and status is not ZSuccess which removes the device. It doesn't make sense tbh, because we set device secure = True and then go to this function and ask for device secure = false otherwise we kick it out from the network.

I have compared the code and tested with other coordinator code, having the same implementation, and I get the same error.

What is the purpose of the device secure = False? Can i just add an else statement there?

Best regards,
Hamza

0 Hamza Kadhum over 4 years ago in reply to Hamza Kadhum

Intellectual 945 points

Hi Ryan,

I found the error. In ZDSecMgrDeviceJoin, status is initialized as ZSuccess but I have somehow removed it and just initialized it as ZStatus_t status;

Well, I'm speechless... Thank you for your time and support Ryan!

Best regards,
Hamza

Zigbee & Thread

Zigbee & Thread forum

CC2652R: Request key is not answered from ZC