VOXL2 BT5.0 Support?

Steven Gonciar

Hi all, we’re seeing a reproducible BLE scan crash on VOXL2 / Starling 2 with SDK v1.8.06 when BLE 5 extended advertising is present.

QRB5165 code path: https://gitlab.com/voxl-public/system-image-build/qrb5165-kernel/-/blob/v1.8.06/net/bluetooth/hci_event.c#L5385

From device captures (see dmesg segments describe below, I don't forum privileges to post the logs), we’re seeing LE Extended Advertising Report (0x0d) events with Num reports up to 6, followed by a kernel NULL deref in the Bluetooth RX path (hci0 hci_rx_work -> process_adv_report -> hci_bdaddr_list_lookup).

This looks consistent with the extended-adv bounds-check issue in hci_le_ext_adv_report_evt() that upstream now guards here:
https://github.com/torvalds/linux/blob/master/net/bluetooth/hci_event.c

Key lines from dmesg:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
Workqueue: hci0 hci_rx_work
pc : hci_bdaddr_list_lookup+0x24/0x60
lr : process_adv_report+0x154/0x408
call trace includes hci_le_meta_evt and hci_event_packet
Bluetooth: Unknown advertising packet type: 0x100
Bluetooth: Unknown advertising packet type: 0x4cff

Have you seen this on QRB5165 / VOXL2 before, and is there already a downstream fix or recommended workaround / SDK version for BLE 5 extended advertising? I pulled in the guards from the latest kernel, testing today.

Related post:
https://forum.modalai.com/topic/5181/bluetooth-integration-on-the-voxl2

Steven Gonciar

For visibility, since this seems related to the old BLE/VOXL discussion here:
https://forum.modalai.com/topic/1730/bluetooth-ble-communication-on-the-voxl-is-it-possible

I was able to get BLE 5.0 extended advertising scanning working on VOXL2 / Starling 2 with an ASUS BT500 / Realtek RTL8761B USB adapter by backporting newer upstream Linux Bluetooth HCI event parsing logic into the QRB5165 4.19 kernel tree. My understanding is future revisions of VOXL will have more up to date kernels that solve this issue without back porting.

The issue we were hitting was with LE Extended Advertising Reports. With BLE 5.0 beacons transmitting extended advertising, the older 4.19 Bluetooth path could mis-handle extended advertising report parsing / event-type bits, leading to bad report handling and, in our case, Bluetooth instability / crashes during scanning.

The relevant upstream Linux changes I used as reference include:

b48b833f9e8a - Bluetooth: HCI: Use skb_pull_data to parse LE Ext Advertising Report event
ad38e55e1c89 - Bluetooth: hci_event: Ignore reserved bits in LE Extended Adv Report
0cadf8534f2a - Bluetooth: hci_event: Mask data status from LE ext adv reports

There are also related Realtek / extended-scan quirk changes upstream, but for our immediate case the stronger LE extended advertising parser backport was enough to stop the crash path and allow scanning.

Validated result:

VOXL2 / Starling 2
QRB5165 4.19 kernel
ASUS BT500 / RTL8761B USB BLE adapter
BLE 5.0 beacons using extended advertising
btmgmt --index 0 find -l successfully reports devices and RSSI
btmon captures LE Extended Advertising Report events
no more Bluetooth NULL pointer dereference / hci_le_ext_adv_report_evt crash during the test
observed all 16 expected beacons and repeated RSSI samples

I’m not proposing this as a merge-ready ModalAI patch, but I put the build changes and notes here in case anyone else needs BLE 5.0 extended advertising / RSSI collection on VOXL2:

https://gitlab.com/steven323/qrb5165-kernel-build-docker

Relevant upstream commit links:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b48b833f9e8a
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ad38e55e1c89
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0cadf8534f2a