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.

[Jørgen Holmefjord]

Hi,

Have you made sure to fully erase the nRF device before programming the application, to make sure there is no commissioning data stored in flash?

Can you post the application log from the light bulb/switch example, to see if this provides any information about what is failing? You can enable more logs and increase the log level of the application as described in the SDK documentation.

Best regards,
Jørgen

[Jørgen Holmefjord]

Hi,

Can you try the suggestion in this post?

Yash_2 said:

Is there a separate log file that is generated? If yes, can you please help me locate that file?

No, I was referring to the console log output that you see on Putty.

Best regards,
Jørgen

[Yash_2]

Hello Jorgen,

While searching for API's to disable the n/w link key transfers I stumbled upon these API's -

ZBOSS - Compile-time configuration parameters
Link -developer.nordicsemi.com/.../group___z_b___c_o_n_f_i_g.html

#define ZB_ROUTER_SECURITY //Defines router security

And found these as well ->

Would either of those be used to disable the Transport key exchange step?

If not, can you please suggest what changes I can do to make it work?

Thanks and Regards,

Yash.

[run_ar]

Hi,
I am sorry, we are currently a little low on zigbee competence due to vacations (and will be for a couple of weeks). But I will try to forward your question to the developers to see if they can help answer your quesiton. I am sorry for the inconvenience.

[run_ar]

Hi,

Yash_2 said:

But considering that the coordinator will not send the Transport key, are there any changes(config or code changes) that I can make in the nrf_router/nrf_endDevice that will skip past those transport key steps?

Here is the answer I got from the zigbee team when forwarding your question:

I don't think so. First, make sure that Digi Xbee Coordinator is configured correctly so it can work with our Zigbee router.

For example, have the customer enabled securtiy at Xbee device? (Encryption Enable (EE) parameter must be set to 1)

[Smart.Enrg]

Thanks run_ar,

run_ar said:

Here is the answer I got from the zigbee team when forwarding your question:

I don't think so. First, make sure that Digi Xbee Coordinator is configured correctly so it can work with our Zigbee router.

For example, have the customer enabled securtiy at Xbee device? (Encryption Enable (EE) parameter must be set to 1)

I am working with Yash on this. Couple of follow-up questions for the team, if you will please: 
1) Digi Xbee based ZC is a 3rd party device already installed in the field, we are trying to connect 
     nRF52833 based ZED, ZR devices to it. As such, we've limited control over ZC's configuration.
     I mean - we can't change settings (like enable security), that will break things for other devices
     on this otherwise working, deployed network, right?

2) Like your recommendation to enable encryption on ZC side; which I agree with but not allowed
    to do:( - is there a way to disable encryption on our side? - i.e. in nRF52833 nRF Connect SDK
    (preferable), or nRF5 (if we must)?

Please advise. Thanks again.

[run_ar]

Hi,

I asked the ZB team, and here is what they say:

1. Most probably, according to XBee documentation:

Enable security

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.

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.

[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.