• State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 24 subscribers
  • Views 97 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 288998
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[Zigbee] ZED Missed Network Key Update

user107702

Hello,

We've encountered an issue where if the ZED missed a network key update, it will not do  trust center rejoin and continue to do secure rejoin

Using nRF5 SDK for Thread and Zigbee 4.2.0 and ZED on nrf52840.

I saw this ticket where this user had the same problem and a solution was provided and reported to be working for sdk 4.1.0. I have tried adding

case ZB_BDB_SIGNAL_DEVICE_REBOOT:
        /* Checking ZB_BDB_STATUS_NO_NETWORK status is necessary to exclude situations, when reboot
         * is failed by some other reason. The same status may occur in case of the failed steering
         * procedure, failed join procedure and failed touchlink join/rejoin, but it is expected
         * to be passed with the different signal */
        if ((status == (zb_uint8_t)RET_ERROR) && (ZB_BDB().bdb_commissioning_status == ZB_BDB_STATUS_NO_NETWORK))
        {
            /* Forced TC rejoin */
            ZB_BDB().bdb_commissioning_step = ZB_BDB_INITIALIZATION;
            ZB_BDB().bdb_commissioning_status = ZB_BDB_STATUS_IN_PROGRESS;
            bdb_commissioning_signal(BDB_COMM_SIGNAL_INIT_TC_REJOIN, 0);
            ZB_BDB().bdb_application_signal = ZB_BDB_SIGNAL_DEVICE_REBOOT;
            break; /* ZB_BDB_SIGNAL_DEVICE_REBOOT */
        }

to our signal handler but did not overwrite the header files. When testing with a key switch, ZED does not act any different.

Is this work around still correct for SDK4.2.0? or is there a more correct way now?

Regards,
Chris

Parents
  • 0

    Hi Amanda,

    Thanks for the patch.
    It would seem that it is intended for NRF Connect rather than NRFSDK for Thread and Zigbee however it seems that `zigbee_app_utils.c` serves the same purpose as `zigbee_helpers.c` in nrfsdk T&Z.

    I added the tc_rejoin_done case to the default signal handler and the section for `reqoin_the_network` as those where the parts relevant to an ZED and should be enough to test with.

    Following the same join, power off, key switch, power on steps from above to test. The ZED will still fail to rejoin after missing the key switch. I'm not sure if this is due to the  Nordic CLI example or the ZED. Would it be possible to confirm with nRF SDK T&Z?

    nwk keys
1100000000000000efcdab8967452301
0000000000000000efcdab8967452301

Reply
  • 0

    Hi Amanda,

    Thanks for the patch.
    It would seem that it is intended for NRF Connect rather than NRFSDK for Thread and Zigbee however it seems that `zigbee_app_utils.c` serves the same purpose as `zigbee_helpers.c` in nrfsdk T&Z.

    I added the tc_rejoin_done case to the default signal handler and the section for `reqoin_the_network` as those where the parts relevant to an ZED and should be enough to test with.

    Following the same join, power off, key switch, power on steps from above to test. The ZED will still fail to rejoin after missing the key switch. I'm not sure if this is due to the  Nordic CLI example or the ZED. Would it be possible to confirm with nRF SDK T&Z?

    nwk keys
1100000000000000efcdab8967452301
0000000000000000efcdab8967452301

Children
No Data
Related
Terms of service