Hello BlueZ maintainers,
I am seeing a systematic link-loss the moment a Nordic nRF52840 (central)
connects to a Raspberry Pi Zero 2 W running BlueZ in *peripheral* role.
BlueZ disconnects immediately after the peer replies “Unsupported Remote
Feature / Unsupported LMP Feature (0x1a)” to an
LL_PERIPHERAL_FEATURE_REQ. Per Core Spec v5.4, that feature exchange is
optional, so a simple UNKNOWN_RSP should not abort the connection.
Environment
-----------
• HW Raspberry Pi Zero 2 W (CYW43438 controller, BT 4.2)
• Kernel ⟨6.12.20+rpt-rpi-v8⟩
• BlueZ 5.66
• bluetoothd started as: `bluetoothd -d -n`
• Peer Nordic nRF52840-DK, Zephyr 3.6.0, SoftDevice Controller v1.6.0
• Pi role Peripheral; simple GATT server advertising via
`bluez-peripheral 0.1.7` Python script
• BR/EDR disabled (`controller-mode = le` in main.conf)
Steps to reproduce
------------------
1. On the Pi
bluetoothd -d -n &
python3 advert.py # advertises, no security required
2. On the nRF52840 central firmware: scan for “Example-Peripheral” and connect.
3. Capture on the Pi with btmon (excerpt below).
> HCI Event: LE Connection Complete (0x3e) plen 19 # handle 0x0040
< HCI Command: LE Read Remote Used Features (0x08|0x0016)
> LE Meta Event: Read Remote Used Features (0x04)
Status: Unsupported Remote Feature (0x1a)
< HCI Command: Disconnect (0x01|0x0006)
Reason: Remote User Terminated Connection (0x13)
An over-the-air sniffer trace shows the same thing at Link Layer level:
Pi (peripheral) sends LL_PERIPHERAL_FEATURE_REQ, the nRF52840
responds LL_UNKNOWN_RSP, and the Pi immediately terminates the link
(PDU log attached).
Expected result
The connection should stay up; BlueZ should tolerate LL_UNKNOWN_RSP for PERIPHERAL_FEATURE_REQ and continue without feature-exchange.
Actual result
BlueZ disconnects with reason 0x13 as soon as the UNKNOWN_RSP appears.
Things I’ve tried
-
Connecting the same Pi peripheral to an Android 14 phone works fine (phone supports the PFR procedure).
-
Connecting the nRF52840 central to another nRF52840 peripheral also works, so the central side is capable of normal operation.
Questions
-
Is the immediate disconnect on 0x1a intentional?
-
If it is unintended, would a patch that ignores UNKNOWN_RSP for LL_PERIPHERAL_FEATURE_REQ be welcome? (Happy to test/submit.)
- If it is intended, can I disable the LL_PERIPHERAL_FEATURE_REQ from being sent in the first place?
Attachments
-
btmon_nrf52840_fail.log– full bluetoothd-d+btmon output -
Ras_dongle_Unsuccessful_connection.pcapng– sniffer trace
(same files referenced in the Nordic DevZone thread¹)
Many thanks for any guidance!
Best regards, Faranak Karimi, IDmelon Technologies, Faranakkarimi.iot@xxxxxxxxx
––– ¹ https://devzone.nordicsemi.com/f/nordic-q-a/120846/bluetooth-le-unsupported-remote-feature-0x1a-error-when-connecting-nrf52840-central-to-raspberry-pi-zero-2w-peripheral Emil Lenngren suggested asking here because “the connection can of course be kept alive despite this problem” and the PFR procedure is optional .
Attachment:
Ras_dongle_Unsuccessful_connection.pcapng
Description: Binary data
Attachment:
btmon_nrf52840_fail.log
Description: Binary data
