Secure Zigbee pro communication with MC1322x devices

[marisa]

I have tried to established a secure Zigbee Pro connection between a KW21D256 device and  some old MC13224 devices I own.

I have checked that everything is well configured to support security (standard security enabled, same network and link (not used) keys, same channel, same Extended PANID, adequate Zigbee library (ZxRsRNPSp2) ).

The code is the one for a Blackbox image, without modifications. The MC13224 is configured as coordinator and the KW21D256 as router.

I have used a sniffer to analyze what occurs in the network. The association process begins correctly. However, once the association process is performed, the router device leaves the network.

I have done the same test without security and everything goes fine. Thus, I assume that the communication problem is caused by the negotiation of communication. But, I can't find which is the problem, since the security configuration of both devices is the same.

Is there any known compatibility problem between both products when security is enabled? Can anybody provide me a hint about how to configure the devices in order to communicate?

Regards,

[AngelC]

Hi Marisa,

Theoretically, there should not be any problem at all. That sounds like Transport key is either not being sent or not being recognized by the joining device. Could you please send me the sniffer log so I could analyze it further? Also, please specify the codebase version you are using in both nodes so we could setup a similar scenario.

Another test you could try would be to join another 1322x with same settings and see what happens. Maybe something might be missing. Again, after checking the sniffer log and replicating the issue I will know the exact route cause. I will be looking forward to your reply.

Regards,

Angel

[marisa]

Dear Angel,

I have done the same trial with different mc1322x devices with the same result. Furthermore, I have the mc1322x firmware deployed in different scenarios; thus, I can assure that the configuration is correct and works, at least with all the mc1322x chips and different mc1322x codebases.

The codebase we use for the mc1322x devices is 3.0.10.  Though I could do a simple trial with other codebases, I want the KW20 chip to talk to our current products. They implement codebase 3.0.10 and It would be difficult to migrate them to more recent codebases due to binay size limitations.

The codebase for the KW20 device is the 4.0.0 one.

I send you a daintree capture file; I used Testool and a dongle sniffer to capture the traffic. I hope it serves you. In this case, the coordinator is a mc1322x device and the dongle a kw20 device. The network key, trust key and master key are the default ones.

If you need more captures or trials, just tell me.

Looking forward to your response.

Regards and thank you for the support,

Marisa

[AlanCollins]

I tried to open the sniffer LOG but I found an unexpected problem... Probably my Daintree version is a little bit old, anyway I tried with Ubiqua too, but found the same problem. I see the LOG is quite small, can you send a picture instead? or else may you record a new LOG using Ubiqua?

This problem seems to be related to the Transport key not being sent by the Trust Center. I read you are using only ZR and ZED, which means you did a "silent join" with the ZR, and then when the ZED joins, the routers has no idea where the Trust center is, because you do not have a coordinator in the network. Then, the 5 seconds of waiting for Transport key from Trust Center will expire and the devices will leave the network. Please try by having the ZC present in the network.

[marisa]

I am using one ZR and one ZC in the network.

I send new captures that can be opened with wireshark.

Regards

Marisa !

[AlanCollins]

Hola Marisa,

     Analyzing Kw20ZR_mc1322xZC LOG, I can see the Transport Key is sent by ZC (pkt 24), but ZR fails to process it. This could be related to a difference in the Trust Center Link Key, or any configuration related to security. I'd like to compare ApplicationConfig.h, and BeeStackConfiguration.h, header files for both projects. Could you please send those? In the meantime, I will generate a couple of projects one for 1322x and the other for KW2x to verify they can connect with security enabled.

[AlanCollins]

Hello marisa. Please let me know how are you doing with this matter. I will have limited access to the internet starting Dic 12 (vacations w/ my children). I'd like to help you to solve this before that. :smileyhappy:

[marisa]

Hi,

Sorry, I have been busy these days. I send you the files you requested.

I hope it helps to identify the problem.

Happy Christmas holidays!

Marisa

[jc_pacheco]

Hello Marisa,

In ARM7 Codebase 3.0.10 setting the network key to a value !=0x00’s means that the network key is pre-configured (The transport key message received over the air is a dummy message (check the APS payload –> key descriptor -> key = 0x00’s)). In this case the remote node should also have the pre-configured network key for a stable communication.

In Kinetis Codebase 4.0.0 or 4.0.1 (Latest BeeKit release until now is BeeKit 3.0.2), the usage of a preconfigured network key is enabled by setting the gNwkKeyPreconfigured flag from beeStackConfigParams_t structure.

Enabling the mentioned flag (see BeeAppInit.c: gBeeStackConfig_init  and BeeStack_Globals.c: gBeeStackConfig) the connection btw 3.0.10 coordinator and 4.0.x Router/End Device will work.

I hope this helps.

Juan Carlos