Using a different pre-configured link key with JN-AN-1216 ControlBridge

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Using a different pre-configured link key with JN-AN-1216 ControlBridge

992件の閲覧回数
pldrouin_
Contributor II

Hi,

I am trying to set a different pre-configured link key for the JN-AN-1216 ControlBridge using JN-SW-4170 version 1840 (the latest), but the control bridge's coordinator is using the '09 key no matter what I do. In ZWGUI I have selected PRECONFIGURED LINK KEY, SQN 0, GLOBAL LINK KEY and tried 01020304050607080910111213141516 as the key. I tried clicking on the "Set Security" right away after "Erase PD" is done, or also at a later stage, but the network key is always transported using the '09 key. How can I make this work?

Thanks!

ラベル(3)
0 件の賞賛
7 返答(返信)

851件の閲覧回数
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Pierre,

Please look at my configuration below. I changed the last byte for testing purposes.

D0D1D2D3D4D5D6D7D8D9DADBDCDDDEDD

However, could you please print the &au8LinkRxBuffer[3] pinter to the key that you are setting?

pastedImage_2.png

Please look at the switch case after set the security

case (E_SL_MSG_SET_SECURITY):

Regards,

Mario 

0 件の賞賛

851件の閲覧回数
pldrouin_
Contributor II

Hi Mario,

I tried using the same settings as you (SQN 1 instead of 0, Unique Link Key instead of Global Link Key, and also the same key as you), However the network key is still transported by encrypting it using the '09 key instead of your key. An end device is also able to join, which should not happen. I tried printing the &auLinkRxBuffer[3] pointer like you requested, and it gave me 0x4004fb3. I tried also printing the actual values (auLinkRxBuffer[3], auLinkRxBuffer[4], etc), and it gave me your key value.

Regards,

P-L

0 件の賞賛

851件の閲覧回数
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Pierre,

Please look at the APP_bSendHATransportKey, this callback is sending the 09 Key. This function is part of the joining process, please look at the au8Key inside there.

Regards,

Mario

0 件の賞賛

851件の閲覧回数
pldrouin_
Contributor II

Hi Mario,

so yes, this is the issue with JN-AN-1216, it is using a hardcoded key in APP_bSendHATransportKey instead of using the value from ZPS_vAplSecSetInitialSecurityState as it should. Replacing au8Key by sBDB.pu8DefaultTCLinkKey seems to work, is that the proper way to fix this?

Regards,

Pierre-Luc

0 件の賞賛

851件の閲覧回数
mario_castaneda
NXP TechSupport
NXP TechSupport

Hi Pierre,

The code is not hardcore, please look at the ZPS_vTCSetCallback that is registering the user-defined callback function on the Trust Centre.

Please look at the ZigBee PRO Stack User Guide

Regards,

Mario

0 件の賞賛

851件の閲覧回数
pldrouin_
Contributor II

Hi Mario,

By hardcoded I meant that the "Set Security" functionality of the control bridge API in JN-AN-1216 does not allow to set the preconfigured link key, as the '09 key is constant in the APP_bSendHATTransportKey function. So the key cannot be set through the API, but only through a modification of the firmware. I noticed that this was fixed for the KW41Z platform. The "Set Security" functionality on that platform works as it should. There the APP_bSendHATTransportKey function is using sBDB.pu8DefaultTCLinkKey instead of a fixed value.

Thanks,

P-L

851件の閲覧回数
pldrouin_
Contributor II

So using sBDB.pu8DefaultTCLinkKey does not quite work either, because it looks like its value gets replaced by the transported key? I am wondering if the key value passed to the ZPS_vAplSecSetInitialSecurityState gets stored somewhere or it gets replaced by the transported key as well? I could always define a new variable to hold the value passed to ZPS_vAplSecSetInitialSecurityState, but it might not be necessary?

Thanks!

0 件の賞賛