Malformed beacon from non-compliant zigbee device causes stack to crash

[tennispedersen]

Describe the set-up

• STM32WB5MMG on custom board
• M0-core loaded with stm32wb5x_Zigbee_FFD_fw.bin v. 1.13.2
• STM32CubeIDE v. 1.9.0
• GNU Tools for STM32 (10.3-2021.10)

Describe the bug In our testing environment (an office building) there is a piece of equipment that continuously broadcasts what looks like a zigbee beacon. According to wireshark the beacon is malformed and I expect this device to be some sort of proprietary (non-conforming) equipment that uses a 2.4 GHz IEEE 802.15.4 transmitter.

However when our board starts scanning for a network it picks up this "beacon" and then the M0 core simply locks up. I would expect the stack to be immune to malformed packets but it looks like it is not.

The M4 host is blocked waiting for EVENT_ZIGBEE_STARTUP_ENDED.

How To Reproduce I have taken our board into a silent environment and set up an offending transmitter to mimic the problematic beacon, and the behaviour of our board is the same: As soon as I turn on the transmitter the M0 core/stack locks up. It appears to always happen on (or after) the last scan attempt but I cannot say for sure.

The raw data in the malformed beacon is: 00 80 56 00 05 FA 07 22 CF 00

Debug console output [M4 APPLICATION] Network config : APP_STARTUP_CENTRALIZED_ROUTER [M0] [00000002.020][PLATFORM] ZbNlmeResetReq : NLME-RESET.request (warmStart = 0) [M0] [00000000.011][PLATFORM] zb_startup_join_nwk_disc : Attempting network discovery. Scans = 3, Duration = 4 [M0] [00000000.012][PLATFORM] nwk_scan_req : MLME-SCAN.request (wpan0): type=1, page=0, mask=0x02108001, dur=4 [M0] [00000000.807][API] Scan Done - unscan channels 0x1 [M0] [00000000.827][PLATFORM] nwk_scan_req : MLME-SCAN.request (wpan0): type=1, page=0, mask=0x02108001, dur=4 [M0] [00000001.622][API] Scan Done - unscan channels 0x1 [M0] [00000001.623][PLATFORM] nwk_scan_req : MLME-SCAN.request (wpan0): type=1, page=0, mask=0x02108001, dur=4

Wireshark dump

[ASELSTM]

ST Internal Reference: 130863

[tennispedersen]

After some tests I found that it is not the content of the "beacon" that causes this issue. It is the length. After appending one byte to the beacon the wireless core no longer hangs during scan.

[ASELSTM]

Hi @tennispedersen,

The issue you reported has been fixed in the frame of version v1.15.0 of the STM32CubeWB published on GitHub.

Thank you again for having reported.

With regards,