Zigbee Router device sometimes joins to 0x0000000000000000 network after factory reset

[pjbuntinx]

I am using NRF Connect SDK v2.5.2. Sometimes, after I factory reset my Zigbee router device, it will immediately join a network with PAN ID 000000000000. I get this with my project but also with the light_bulb sample. How can I prevent my device from doing this? Below you can view the logs. Just before the logs, the button was held to factory reset the device. The device had not joined a network before resetting. 

Many thanks,

Pieter-Jan

I: Network left (leave type: 0)
I: Joined network successfully (Extended PAN ID: 0000000000000000, PAN ID: 0xffff)
I: Network rejoin procedure stopped.

[AHaug]

Hi

Sometimes, after I factory reset my Zigbee router device, it will immediately join a network

Could you clarify the following when you say "a network":

Do you have multiple networks up, i.e is it a random network it joins? Is it establishing a new network that the router joins?

Do you have a sniffer trace for the device throughout the procedure you describe? 

The log also says I: Network rejoin procedure stopped. Indicating that the rejoin procedure stops

Kind regards,
Andreas

[pjbuntinx]

This happens with or without a coordinator in the proximity. When it is, It does not matter whether the coordinator is allowing new devices or not. The network the device joins is not one that should be existing.
This is not applicable to the light bulb example, but for my own device's code, I am using install_codes. So, it should normally not be possible to join another network without having the correct install code added to the coordinator. 

[AHaug]

My initial thought as well is that this should not be possible without a coordinator and/or Trust Center

Could you provide a sniffer trace lapsing over the time span of the procedure?

Could you provide a minimal sample and descriptions for how to reproduce this?

Kind regards,
Andreas

[pjbuntinx]

I have now used the Zigbee light_bulb example in NRF SDK v2.7.0. What I did was just flash the example to an NRF52840 DK board without any changes in the kconfig. To get it to join this 0x0000 network I had to factory reset the board multiple times (long pressing button 4). This in combination with resetting the board let me reproduce the problem. On Wireshark there does not seem to be happening anything special. There are only beacon requests. 

It does seem it is more difficult to reproduces the problem on SDK v2.7.0. On v2.5.2, it seems to happen  most of the time after just 1 factory reset (right after a fresh "erase and flash to board")

Below you can find the log.

*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
I: Starting ZBOSS Light Bulb example
I: 2 Sectors of 4096 bytes
I: alloc wra: 0, fe8
I: data wra: 0, 0
I: Set level value: 255
I: ZBOSS Light Bulb example started
I: Production configuration is not present or invalid (status: -1)
I: Zigbee stack initialized
I: Device started for the first time
I: Start network steering
I: Started network rejoin procedure.
I: Network steering was not successful (status: -1)
I: nRF5 802154 radio initialized
*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
I: Starting ZBOSS Light Bulb example
I: 2 Sectors of 4096 bytes
I: alloc wra: 0, fe8
I: data wra: 0, 0
I: Set level value: 255
I: ZBOSS I: Production configuration is not present or invalid (status: -1)
I: Zigbee stack initialized
I: Device started for the first time
I: Start network steering
I: Started network rejoin procedure.
Light Bulb example started
I: Network steering was not successful (status: -1)
I: Network steering was not successful (status: -1)
I: Network steering was not successful (status: -1)
I: Network steering was not successful (status: -1)
I: Network steering was not successful (status: -1)
I: Network left (leave type: 0)
W: Device not in a network - cannot enter identify mode
W: Device not in a network - cannot enter identify mode
I: Network left (leave type: 0)
W: Device not in a network - cannot enter identify mode
W: Device not in a network - cannot enter identify mode
W: Device not in a network - cannot enter identify mode
I: nRF5 802154 radio initialized
*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
I: Starting ZBOSS Light Bulb example
I: 2 Sectors of 4096 bytes
I: alloc wra: 0, fe8
I: data wra: 0, 0
I: Set level value: 255
I: ZBOSS I: Production configuration is not present or invalid (status: -1)
I: Zigbee stack initialized
I: Device started for the first time
I: Start network steering
I: Started network rejoin procedure.
Light Bulb example started
I: Network steering was not successful (status: -1)
I: Network steering was not successful (status: -1)
I: Network left (leave type: 0)
I: Network steering was not successful (status: -1)
W: Device not in a network - cannot enter identify mode
I: Network steering was not successful (status: -1)
I: Network left (leave type: 0)
I: Network steering was not successful (status: -1)
I: Network left (leave type: 0)
I: Network steering was not successful (status: -1)
I: Network steering was not successful (status: -1)
I: nRF5 802154 radio initialized
*** Booting nRF Connect SDK v2.7.0-5cb85570ca43 ***
*** Using Zephyr OS v3.6.99-100befc70c74 ***
I: Starting ZBOSS Light Bulb example
I: 2 Sectors of 4096 bytes
I: alloc wra: 0, fe8
I: data wra: 0, 0
I: Set level value: 255
I: ZBOSS I: Production configuration is not present or invalid (status: -1)
I: Zigbee stack initialized
I: Device started for the first time
I: Start network steering
I: Started network rejoin procedure.
Light Bulb example started
I: Network steering was not successful (status: -1)
I: Network steering was not successful (status: -1)
I: Network left (leave type: 0)
I: Joined network successfully (Extended PAN ID: 0000000000000000, PAN ID: 0xffff)
I: Network rejoin procedure stopped.

And here is the wireshark capture:
capture light bulb example.pcapng

[AHaug]

Thank you for providing this. 

Based on your description and reproduction in multiple SDKs this seems to be a bug. I've created an internal ticket to investigate this further and I'm currently waiting for some feedback from the Zigbee team for this case.

I'll update you as soon as I know something

Kind regards,
Andreas

[pjbuntinx]

Hi AHaug 

Do you perhaps have any update on this?

Kind regards,
Pieter-Jan

[AHaug]

Hi Pieter-Jan,

The latest update I received from the Zigbee team is they are working with testing and recreating the behaviour reported. I will try to update you before the weekend with any results and/or follow up questions from the team.

Thank you for your patience and kind regards,
Andreas