[BUG] ble-wifi commissioning fails BLE connection on ubuntu 24.04 LTS on raspberry pi 4

[enkiusz]

Reproduction steps

During commissioning tests we have found that the ble-wifi commissioning flow fails when the device (chip-light) is running on a recent kernel on a raspberry pi 3 and 4 with the controller running on a Linux PC. The problem occurs immidiately after the device is discovered by chip-tool and PASE is attempted. The BLE connection is established and closed shorty after preventing this process from even starting. This looks like a regression between a non-updated ubuntu-22.04 from (working) and more recent debian 12 and ubuntu 24.04 LTS (non-working).

Bug prevalence

Always

GitHub hash of the SDK that was being used

1114858

Platform

raspi

Platform Version(s)

No response

Anything else?

All tests so far have been performed between an amd64 PC with a CSR8510 A10 Bluetooth dongle running either:

• ubuntu 24.04.5 LTS (Linux 6.8.0-52-generic, bluez 5.72-0ubuntu5 with --experimental)
• a VM with ubuntu 22.04.5 LTS (Linux 5.15.0-133-generic, bluez 5.64-0ubuntu1.4 with --experimental), USB dongle passed through to VM

and a raspberry pi 4 model B running either:

• ubuntu server 22.04 from https://old-releases.ubuntu.com/releases/22.04/ubuntu-22.04-beta-live-server-arm64.iso (Linux 5.15.0-1003-raspi, bluez 5.64-0ubuntu1 with --experimental)
• ubuntu server 24.04.2 LTS (Linux 6.8.0-1018-raspi, bluez 5.72-0ubuntu5 with --experimental)

The following controller / device combos have been tested:

Device ↓ controller →	raspberry 4 ubuntu 22.04	raspberry pi 4 ubuntu 24.04	amd64 PC ubuntu 22.04	amd64 PC ubuntu 24.04
raspberry 4 ubuntu 22.04				OK
raspberry 4 ubuntu 24.04			FAIL (2)	FAIL (1)
amd64 VM ubuntu 22.04		OK		OK
amd64 PC ubuntu 24.04			OK

More detailed investigation points to the kernel update being the reason for this regression. We are however unable to bisect it to find the offending commits due to non-trivial history of https://github.com/raspberrypi/linux.git when compared to the upstream. Without this step it does not make sense to report this to linux upstream yet. Additionally a simpler PoC of the problem is needed. This report is meant to be a record of the initial findings.

Logs for both the controller and device from Matter SDK commands, bluez and hcidumps are provided for combo (1). The behaviour for the other failing combo (2) is identical.

amd64-ctrl-ubuntu-24.04-hcidump.dump.gz
amd64-ctrl-ubuntu-24.04-bluez.log.gz
amd64-ctrl-ubuntu-24.04-chip-tool.log.gz
raspi-device-ubuntu-24.04-bluez.log.gz
raspi-device-ubuntu-24.04-chip-light.log.gz
raspi-device-ubuntu-24.04-hcidump.dump.gz