• State Verified Answer
  • Replies 11 replies
  • Subscribers 75 subscribers
  • Views 253 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 344204
Options

Bluetooth LE: “Unsupported Remote Feature (0x1a)” error when connecting nRF52840 central to Raspberry Pi Zero 2W peripheral

Faranak Karimi

I’m working on a BLE setup where:

  1. A Nordic nRF52840-DK runs as the Central (it scans for devices with a specific name, then initiates a connection).

  2. A Raspberry Pi Zero 2W (64-bit Raspberry Pi OS) acts as the Peripheral, advertising using BlueZ.

Right after the connection is formed, BlueZ on the Raspberry Pi sends an LE Read Remote Used Features request. It then receives an Unsupported Remote Feature / Unsupported LMP Feature (0x1a) error in response. Immediately after that, BlueZ on the Pi terminates the connection.

Below is the relevant snippet from the btmon log:

    > HCI Event: LE Meta Event (0x3e) plen 19                                                                                 #47 [hci0] 447.240698 
      LE Connection Complete (0x01)
        Status: Success (0x00)
        Handle: 64
        Role: Peripheral (0x01)
        Peer address type: Random (0x01)
        Peer address: E9:F5:BF:3A:12:62 (Static)
        Connection interval: 30.00 msec (0x0018)
        Connection latency: 0 (0x0000)
        Supervision timeout: 4000 msec (0x0190)
        Central clock accuracy: 0x07
@ MGMT Event: Device Connected (0x000b) plen 13                                                                      {0x0001} [hci0] 447.241245 
        LE Address: E9:F5:BF:3A:12:62 (Static)
        Flags: 0x00000000
        Data length: 0
> HCI Event: Vendor (0xff) plen 5                                                                                         #48 [hci0] 447.240711 
        55 00 00 40 00                                   U..@.
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2                                                          #49 [hci0] 447.241592 
        Handle: 64 Address: E9:F5:BF:3A:12:62 (Static)
> HCI Event: Command Status (0x0f) plen 4                                                                                 #50 [hci0] 447.242192 
      LE Read Remote Used Features (0x08|0x0016) ncmd 1
        Status: Success (0x00)
@ RAW Open: btmon (privileged) version 2.22                                                                                 {0x0002} 447.245682 
@ RAW Close: btmon                                                                                                          {0x0002} 447.245959 
> ACL Data RX: Handle 64 flags 0x02 dlen 7                                                                                #51 [hci0] 447.271008
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 247
> HCI Event: LE Meta Event (0x3e) plen 12                                                                                 #52 [hci0] 447.421202
      LE Read Remote Used Features (0x04)
        Status: Unsupported Remote Feature / Unsupported LMP Feature (0x1a)
        Handle: 64 Address: E9:F5:BF:3A:12:62 (Static)
        Features: 0x1f 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          LE Encryption
          Connection Parameter Request Procedure
          Extended Reject Indication
          Peripheral-initiated Features Exchange
          LE Ping
< HCI Command: Disconnect (0x01|0x0006) plen 3                                                                            #53 [hci0] 447.445148
        Handle: 64 Address: E9:F5:BF:3A:12:62 (Static)
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4                                                                                 #54 [hci0] 447.445744 
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4                                                                            #55 [hci0] 447.481970
        Status: Success (0x00)
        Handle: 64 Address: E9:F5:BF:3A:12:62 (Static)
        Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Device Disconnected (0x000c) plen 8                                                                    {0x0001} [hci0] 447.482030 
        LE Address: E9:F5:BF:3A:12:62 (Static)
        Reason: Connection terminated by local host (0x02)

After this, the Raspberry Pi decides to disconnect.

I checked the reported feature sets on both sides (by running cat /sys/kernel/debug/bluetooth/hci0/features on the Pi) and they seem to match:

 0: bf fe cf fe db ff 7b 87 
1: 02 00 00 00 00 00 00 00 
2: 7f 0b 00 00 00 00 00 00 
LE: 1f 00 00 00 00 00 00 00

I also made sure BR/EDR is disabled on the Pi. Upgrading BlueZ did not fix the issue.

Questions

  • Why is BlueZ showing “Unsupported Remote Feature / Unsupported LMP Feature (0x1a)” even though the feature bits appear consistent?

  • Is there a way to force BlueZ to ignore that 0x1a error and remain connected, or otherwise work around it so the connection won’t be dropped immediately?

Any pointers or suggestions would be greatly appreciated!

P.S.
I have tried with a custom project on NRF52840-DK where I disabled the MTU Exchange request. and also with ble_app_hrs_c example code on NRF52840-DK and a simple python script advertising as heartrate monitor on Raspberrypi zero 2w. both run to this error.

Parents
  • 0

    Have you tried running nRF Sniffer on a separate devkit to see what's going on in the air traffic?

  • 0 in reply to Emil Lenngren

    Yes. Since my original problem was the connection disruption between Raspberrypi zero 2w and a customized nrf52840 dongle, after your recommendation used NRF52840-DK as an sniffer to capture the traffic between these 2 devices.


    the selected frames are the ones that are transferred after connection, the connection seems to end after these exchanges. I attached the complete recorded details in "Ras_dongle_Unsuccessful_connection.pcapng".
    I also attached the recording of connection between my Raspberrypi and phone(In central mode), which is successful. I thought this might be helpful since both nrf52 and my phone use bluetooth version 5 and raspberry's bluetooth version is 4.

    Ras_dongle_Unsuccessful_connection.pcapng

    Ras_Phone_Successful_connection_and_pairing_filtered.pcapng

    Thanks in advance for your help.

  • +1 in reply to Hung Bui

    I can see that the LL_UNKNOWN_RSP contains the "unknown type" field LL_PERIPHERAL_FEATURE_REQ, which means that the RPi sent this request and the central (nrf52) does not support this type of request. It seems very harsh that the RPi disconnects the connection due to this. The connection can of course be kept alive despite this problem. Maybe you can ask on the BlueZ mailing list why this behaviour exists? The Peripheral Feature Request is an optional feature to support, so it should not be uncommon for this to happen.

    Otherwise, maybe you can upgrade the nRF Bluetooth stack to a newer version supporting this request?

  • 0 in reply to Hung Bui

    Thanks for the response. You guys were absolutely right, there were some frames missing, I tried sniffing the frames again and this time event counter seems to increase smoothly

    and now we can see the "LE Read Remote Used Features" and also the terminate request coming from Raspberrypi.
    Ras_dongle_Unsuccessful_connection_recapture.pcapng
    I attached the recorded file again.

  • 0 in reply to Emil Lenngren
    Emil Lenngren said:
    Maybe you can ask on the BlueZ mailing list why this behaviour exists?

    I will try to contact the for sure, as this seems odd to disconnect the connection due to a 0x1a.

    Emil Lenngren said:
    Otherwise, maybe you can upgrade the nRF Bluetooth stack to a newer version supporting this request?

    This is my first time around nRF Devices and Bluetooth stack in general, I am not sure how can I do this? I already use the most recent SoftDevice provided by Nordic. If you could go into more details on how can I achieve this, that would be massive help.

  • 0 in reply to Faranak Karimi

    Thanks Faranak, 
    I think it's clear now. The BlueZ sent the LL_PERIPHERAL_FEATURE_REQ, the nRF52 replied with UNKNOWN_RSP as it doesn't recognize this request. After that BlueZ terminate the connection. 

    You can follow what Emil suggested, update to newer BLE stack from Nordic. 
    Please be aware that nRF5 SDK (and the softdevice included with nRF5 SDK) has been put on maintenance mode since 2019. We haven't added new feature to it since then. 


    The new platform is nRF Connect SDK and the Softdevice controller stack included in the nRF Connect SDK. 

    You can get started with nRF Connect SDK using our Dev Academy course here: https://academy.nordicsemi.com/

  • 0 in reply to Hung Bui

    Hi Hung,

    thank you very much for digging into the trace and pointing out what’s happening.
    If I understand your explanation correctly, Because nRF5 SDK (and the full SoftDevice that comes with it) has been frozen in maintenance mode since 2019, support for newer LL procedures such as LL_PERIPHERAL_FEATURE_REQ never made it in.

    I checked the link you provided and my understanding is that the new SDK is based on ZypherOS and the APIs are different from what was used in older SoftDevice versions. Since my project is adding a feature to a semi-large legacy codebase, migrating to the new nRF Connect SDK is costly.

    Could you please confirm that this reading is correct?
    And, just to be sure:

    • There is no newer SoftDevice for nRF5 SDK that already supports LL_PERIPHERAL_FEATURE_REQ, right?

    • If we stay on nRF5 SDK for the time being, the only practical fix is to disable the Peripheral-Feature procedure in BlueZ (or patch BlueZ to ignore the UNKNOWN_RSP). Do you see any other route?

    Thanks again for the quick and helpful answer!

Reply
  • 0 in reply to Hung Bui

    Hi Hung,

    thank you very much for digging into the trace and pointing out what’s happening.
    If I understand your explanation correctly, Because nRF5 SDK (and the full SoftDevice that comes with it) has been frozen in maintenance mode since 2019, support for newer LL procedures such as LL_PERIPHERAL_FEATURE_REQ never made it in.

    I checked the link you provided and my understanding is that the new SDK is based on ZypherOS and the APIs are different from what was used in older SoftDevice versions. Since my project is adding a feature to a semi-large legacy codebase, migrating to the new nRF Connect SDK is costly.

    Could you please confirm that this reading is correct?
    And, just to be sure:

    • There is no newer SoftDevice for nRF5 SDK that already supports LL_PERIPHERAL_FEATURE_REQ, right?

    • If we stay on nRF5 SDK for the time being, the only practical fix is to disable the Peripheral-Feature procedure in BlueZ (or patch BlueZ to ignore the UNKNOWN_RSP). Do you see any other route?

    Thanks again for the quick and helpful answer!

Children
Related
Terms of service