Hi Faranak,
On Wed, Apr 23, 2025 at 5:33 AM Faranak Karimi
<faranakkarimi.iot@xxxxxxxxx> wrote:
>
>
> 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.
This was introduced a really long time ago:
commit 0fe29fd1cd77ffbdb8e36ec1715868d9d8011c9b
Author: Marcel Holtmann <marcel@xxxxxxxxxxxx>
Date: Wed Apr 8 09:05:27 2015 -0700
Bluetooth: Read LE remote features during connection establishment
When establishing a Bluetooth LE connection, read the remote used
features mask to determine which features are supported. This was
not really needed with Bluetooth 4.0, but since Bluetooth 4.1 and
also 4.2 have introduced new optional features, this becomes more
important.
This works the same as with BR/EDR where the connection enters the
BT_CONFIG stage and hci_connect_cfm call is delayed until the remote
features have been retrieved. Only after successfully receiving the
remote features, the connection enters the BT_CONNECTED state.
Signed-off-by: Marcel Holtmann <marcel@xxxxxxxxxxxx>
Signed-off-by: Johan Hedberg <johan.hedberg@xxxxxxxxx>
We don't seem to be doing anything with conn->features so perhaps
!status can be just ignored, that said it sort of weird coming from
nordic, or perhaps it only responds like that when connection as
central?
> 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 .
>
>
--
Luiz Augusto von Dentz
