Routers (nRF54L15) stop retransmitting NWK broadcasts after several hours.

[Jesus Iriarte Ruiz]

Hi,

I’m observing an issue in a Zigbee network where, after several hours of correct operation, the routers stop retransmitting the NWK broadcast frames sent by the coordinator.

I’m attaching two captures:

• Jun17_no_broadcasting.pcapng → The problem is already present.

• Jun17_after_power_cycle.pcapng → After power‑cycling one router, retransmissions resume normally

The network key (to decrypt traffic) is: 0x00000000000000000000000000001234



What I am seeing in the capture

To view the broadcasts sent by the coordinator (NWK source 0x0000, destination 0xFFFF), I use the filter (zbee_nwk.src == 0x0000) && (zbee_nwk.dst == 0xffff)
I can see 355 broadcast frames from the coordinator.

To view the retransmissions that routers should perform, I use the filter ((zbee_nwk.src == 0x0000) && (zbee_nwk.dst == 0xffff)) && !(wpan.src16 == 0x0000)
This should show all routers forwarding those broadcasts. However, I see none.
It looks like all routers have stopped forwarding NWK broadcasts.

If I power‑cycle one router, the problem disappears immediately: that router starts retransmitting broadcasts again. This behavior is visible in the second capture.

Network setup
1 coordinator (DIGI)

8 routers (all nRF54L15)

Two routers are physically very close to the coordinator

No Trust Center (distributed security)

Zigbee R23 Add‑on v1.3.0

nRF Connect SDK v2.9.2

Multiprotocol option enabled, but BLE is currently disabled

NOTE: Same Zigbee application running on nRF52840 (Zigbee R22) works perfectly; we migrated to nRF54L15 because nRF52840 is not recommended for new designs, but we are facing several issues on the new platform.

Questions:

Is this a known issue with the Zigbee R23 Add‑on or with the nRF54L15 platform?

Are there any known conditions where routers may stop forwarding NWK broadcasts?

Is there any recommended workaround or configuration to avoid this behavior?

Could this be related to multiprotocol support even if BLE is disabled?

Any debugging steps you recommend to identify why routers stop retransmitting?

Thanks in advance.

Jun17_no_broadcasting.pcapngJun17_after_power_cycle.pcapng

[Elfving]

Hi, and thanks for the detailed report. 

Would you mind getting me the logs from one of these failing routers, as well as the sniffer trace showing the moment it fails, and you reboot it? Not just before and after. Comparing these two (logs and trace I mean) would be interesting.

There is a lot of broadcasts here, so I wonder if things have hit some sort of limit somewhere. 

Is this a known issue with the Zigbee R23 Add‑on or with the nRF54L15 platform?

Are there any known conditions where routers may stop forwarding NWK broadcasts?

None regarding this that I know of yet. There are ofcourse some issues though.

Could this be related to multiprotocol support even if BLE is disabled?

This part is interesting. Although I don't see how it could relate, have you tried it without multiprotocol enabled?

Regards,

Elfving

[Jesus Iriarte Ruiz]

Thanks Elfving,

I initially created the ticket as public. Is it possible to change it to private?

Regarding your requests, the only one I can address for now is providing the part of the sniffer trace where the issue appears: file Jun17_two_hours.pcapng.

In that capture you can see that the coordinator was periodically sending permit join request frames (one per minute). Using the filter (zbee_aps.zdp_cluster == 0x0036) && (zbee_nwk.src == 0x0000) you can see those frames.

You will notice that initially routers 0x584a and 0x1d10 were retransmitting those frames.

At some point, 0x1d10 stopped retransmitting them (its last retransmission was at 18:59:44), while 0x584a continued retransmitting normally. As you will see, 0x1d10 is still alive. It is still able to act as a router for unicast frames generated by the coordinator. The only frames it stops forwarding are the broadcast ones.
Jun17_two_hours.pcapng

Additionally, I would like to share the result of another test I performed during the weekend. I created a network with five nRF52840 routers (ZB R22) and five nRF54L15 routers (ZB R23 + multiprotocol). When I checked the network again on Monday, I verified that all five nRF52840 routers were still retransmitting broadcasts, while all five nRF54L15 routers had stopped doing so.

So the issue is solid and easy to reproduce. I don’t have sniffer traces to share for this particular test.

I will try running without multiprotocol enabled, as you suggested, to see if I observe any difference.

Regards,

Jesús