• State Verified Answer
  • Locked Locked
  • Replies 9 replies
  • Subscribers 24 subscribers
  • Views 89 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

  • 0

    Hi, 

    I am checking with the team for your case and will reply later. 

    Regards,
    Amanda

  • 0

    Hi Amanda,

    Was there any update from the Zigbee team?

    Regards,

    Chris

  • 0

    Hi, 

    Unfortunately, not yet. They are still investigating the case. I will update later if we have anything.

    -Amanda

  • 0

    I have spent some more time looking at this and found that:

    1.  The work around has an error - 
      (status == (zb_uint8_t)RET_ERROR)
      and is always false which would explain absence of change in behavior.
    2. I found the below:

    /// file: zdo_commissioning_bdb.c

static void bdb_initialization_machine(zb_uint8_t param)
{
    ...
        case BDB_COMM_SIGNAL_NWK_JOIN_FAILED:
    {
      TRACE_MSG(TRACE_ZDO1, "Rejoin failed, secured %hd", (FMT__H, bdb_is_in_tc_rejoin()));

#if 0
      /* TC rejoin should be invoked only if we have unique TCLK or if it is directly allowed in
       * application to perform TC rejoin with legacy ZC.
       * To prevent infinite rejoins loop here, TC rejoin will be performed only once, but application
       * will receive ZB_BDB_SIGNAL_TC_REJOIN_DONE to choose a next action */
      if (!bdb_is_in_tc_rejoin() && ((zb_zdo_tclk_valid() && (zb_aib_get_coordinator_version() >= 21))
          || zb_aib_tcpol_get_allow_unsecure_tc_rejoins())
#ifdef ZB_REJOIN_BACKOFF
          && !zb_zdo_rejoin_backoff_is_running()
#endif
          )
      {
        /* Perform TC rejoin */
        TRACE_MSG(TRACE_ZDO1, "Perform TC rejoin", (FMT__0));
        bdb_commissioning_signal(BDB_COMM_SIGNAL_INIT_TC_REJOIN, param);
      }
      else
#endif
      {
        TRACE_MSG(TRACE_ZDO1, "Can't find network", (FMT__0));
        ZB_BDB().bdb_commissioning_status = ZB_BDB_STATUS_NO_NETWORK;
        ZB_BDB().bdb_tc_rejoin_active = ZB_FALSE_U;

        bdb_commissioning_signal(BDB_COMM_SIGNAL_INIT_FINISH, param);
      }
    }
    break;
    
    ...
}

    Which seems to perform the same thing as the original work around.

    I'm trying to confirm if either of these indeed fix the issue by using the CLI example on an additional nrf52840 with the following setup:

    1. ZC has 
      zb_secur_set_tc_rejoin_enabled(true);
      added to main() before the stack is started
    2. bdb ic policy enable
      is set
    3. After starting, the ED IC is added
    4. ED powered on and connected to the ZC
    5. ED is powered off.
    6. ZC performs the nwk key switch - 
      zb_secur_nwk_key_switch_procedure(0)
    7. ED is powered on after the key switch procedure has been completed.

    I can observe the ZED get the 

    ZB_BDB_SIGNAL_TC_REJOIN_DONE
    signal, but always with a failed status code.

    Perhaps I am now just missing something on the ZC side?

    Regards,

    Chris

  • +1

    Hi, 

    There is indeed a bug in the stack that disallows the ZC to do the TC rejoin. We managed how to go around this (attached workaround:  ). This workaround disables an alarm scheduled by the stack when a device is trying to rejoin with an outdated network key.

    Regards,
    Amanda

Related
Terms of service