This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
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

ZBOSS accepts join after leave with no rejoin

We originally saw (and reported) this problem with nRF5 SDK 4.1.0.  We switched to nRF Connect SDK 1.6.0 which did not exhibit this problem.  Now we just tested with nRF Connect SDK 1.7.0 and the problem is back.  

We see this in the zboss release notes and am wondering if they're just going back and forth with an incorrect fix:

  • [ZBS-98] Rejoin after Leave+Rejoin at ZR is broken in r23 - maybe, in r22 also

Commissioning was NOT enabled at the time of the leave request.

The device all successfully left the network. 

In 1.6.0 we would see the devices try to join again but they would be rejected with the device authorization signal showing status 2.

In 1.7.0 we see that they are allowed to rejoin with the device authorization signal showing status 0, even though commissioning was not enabled.

  • Hi,

    If your routers are still based on the nRF5 SDK v4.1.0, then that might explain why this is happening, as the fix is only in nRF Connect SDK for now. 

    Could you please try this workaround on your routers and see if you are still seeing this issue?

    Add the following:

    #ifndef ZB_ED_ROLE
    void nwk_permit_timeout(zb_uint8_t param);
    /**@brief Close network for joining locally as fast as possible.
     *
     * This function is called as a workaround for issue described in KRKNWK-5255.
     *
     * @param[in] bufid   Reference to the Zigbee stack buffer.
    */
    static void close_network_locally(zb_bufid_t bufid)
    {
        if (bufid)
        {
            zb_nlme_permit_joining_request_t *req_param = ZB_BUF_GET_PARAM(bufid, zb_nlme_permit_joining_request_t);
            req_param->permit_duration = 0;
            zb_nlme_permit_joining_request(bufid);
            NRF_LOG_INFO("Zigbee network closed");
        }
        else
        {
            /* If it was impossible to get a free buffer immediately,
             * schedule closing the network.
             */
            zb_ret_t zb_err_code = zb_buf_get_out_delayed(close_network_locally);
            if (zb_err_code != RET_OK)
            {
                NRF_LOG_ERROR("Unable to get buffer or schedule network close operation.");
            }
        }
    }
    #endif

    Call the function from ZB_ZDO_SIGNAL_LEAVE_INDICATION signal handler:

    #ifndef ZB_ED_ROLE
                    /* Close Zigbee network locally due to KRKNWK-5255. */
                    close_network_locally(zb_buf_get_out());
                    zb_time_t timeout_bi;
                    if ((zb_schedule_get_alarm_time(nwk_permit_timeout, ZB_ALARM_ANY_PARAM, &timeout_bi) != RET_OK) ||
                        (timeout_bi == 0))
                    {
                        close_network_locally(zb_buf_get_out());
                    }
                    else
                    {
                        NRF_LOG_INFO("Unable to close Zigbee network - network is opened vie permit join command (scheduled: %d, timeout: %d).",
                            zb_schedule_get_alarm_time(nwk_permit_timeout, ZB_ALARM_ANY_PARAM, &timeout_bi),
                            timeout_bi);
                    }
    #endif

    Best regards,

    Marte

  • The suggested workaround for KRKNWK-5255 on nRF5 routers seems to have resolved this.  

    Thanks!

Related