Nrf router and end device with Digi Xbee Coordinator

[Yash_2]

Hello,

I am using nrf sdk 1.5.1 and trying to connect the Nrf ZigBee router(light bulb example) with Digi Xbee Coordinator but it doesn't seem to connect. I observed the same when I tried to connect nrf end device(light switch example). 

Note - the digi xbee coordinator is tested and working with the digi end device and router

I have attached the sniffer log for more information.

IG_nrfRouter.pcapng

Any help on this is appreciated.

Thanks and Regards,

Yash.

[Smart.Enrg]

Thanks run_ar,

run_ar said:

To enable security on a device, the Encryption Enable (EE) parameter must be set to 1. When the parameter value changes, the XBee module leaves the network (PAN ID and channel) it was operating on and attempt to form or join a new network. If you set EE to 1, all data transmissions are encrypted with the network key.

As mentioned in my original post - we have linited access to 3rd party ZC and enabling encryption as you suggested might help nRF ZED join the network but will break rest of them who are current using existing unencrypted network.

run_ar said:

2. I don't think this is possible to completely disable encryption on our side - I am not aware of any API nor configuration option. Also, this is an unusual approach to completely disable security/encryption for the whole network.

In this context, trying to understand what are these following TC rejoin settings meant to do? Was hoping they will help disable encryption of NCS/ nRF ZED side.

[Yash_2]

Adding to Smart.Enrg here,

I used the zb_secur_set_tc_rejoin_enabled(zb_bool_t enable); function as shown in the following link,

https://devzone.nordicsemi.com/f/nordic-q-a/68410/how-to-use-the-zboss-zb_secur_set_tc_rejoin_enabled-api-call/280339#280339

I used it before the start of the Zigbee thread, but using either enable or disable in params didn't have any behavioral impact on the functioning of the nrf Router.

I am trying to understand the significance of the function(zb_secur_set_tc_rejoin_enabled) and where and in which scenarios should the function be used?

Thanks and Regards,

Yash.

[run_ar]

According to Zigbee Specification zigbee Document 05-3474-22,

4.6.3.3.2 Trust Center Rejoin
A Trust Center Rejoin is used when a device may no longer have the current network key and therefore should not
secure the NWK rejoin command. If the network is using a different network key then the device using the old
network key will be rejected. A Trust Center rejoin is a NWK Rejoin command where the command is sent without
NWK layer security and allows a device to request the current active network key. Figure 4-24 illustrates a trust center rejoin operation.

This have nothing to do with device association. This is mechanism for ZED which has already joined the network (received NWK key) but missed the NWK key update for some reason.

[Yash_2]

Hello run_ar,

Understood, Thank you.

Given that the coordinator does not send the network key in the Transport frame, is there any workaround/code_change you would suggest that might force the nrf router to ignore the key check and proceed with the further functions?

Thanks and Regards,

Yash

[run_ar]

Hi,

I am sorry, as mentioned that is not something we support. It would likely mean having to rewrite parts of the security related code and breaking test implementations. Possibly causing other issues with the code as well. So not something we would recommend.