BlueNRG-M2SA: Controller rejects LE Read Remote Supported Features with status "busy"

[TeoCarda]

Describe the bug

I'm experiencing issues when connecting to a bonded iOS peripheral using BTstack on an embedded system with a BlueNRG-M2SA controller.

My device acts as the central (master).
Upon connection, it initiates LE Read Remote Features and then restores encryption.

With an iphone SE I have no issue during conncetion
With an Iphone 17 Pro I am facing problem during connection

Expected behavior

The bonded iOS device should connect without issues, regardless of the iPhone model.

HCI Packet Logs
IOS btstack.zip

Attached you can find:
IphoneSE_working.pklg: This is the trace of the working Iphone SE
Iphone17Pro_NW.pklg: This is the trace of the not working Iphone 17

To me it seems there are some problem when handling request the comes in between the "SENT LE Read Remotes Features" and the "RCVD LE META (LE read Remotes Features Complete)".

In the working log, the "Rcvd Read By Group Type Request, Primary Service, Handles: 0x0001..0xffff" packet coming from the phone comes after the Read remote features complete command. (And it seems to be ignored?)

In the not working one, the "Rcvd Read By Group Type Request, Primary Service, Handles: 0x0001..0xffff" comes before having completed the command, a error response is sent and then no read remote feature event comes from the controller.

Sincerly, I don't know if it is a stack problem, or if there's something controller side: The controller direcrly answer to the "Sent LE Read Remote Features" with "Number of allowed command packets: 1" event if it is still processing the Read Remote features command.

Environment: (please complete the following information):

• Current BTstack branch: develop (8b154a3)
• Bluetooth Controller Bluenrg-m2sa
• Remote device: iphone 17 Pro with 26.1. Iphone SE with 18.6.2

[mringwal]

Hi there.

In general, the Controller is supposed to send a HCI Command Status Event for anything that cannot be answered immediately. And that's what happens in both logs.

However, in the iPhone 17 Pro log, the Controller responds with "Controller Busy" in the Command Status which I wouldn't expect here. Could you check that you have the latest version and if yes, create a ticket with STM, add me as "collaborator" or similar and as if that's the expected behavior?

Asides from this, there's no problem when the LE Read Remote Supported Features fails. It was added as a workaround for a different Controller.

[TeoCarda]

Hello #mringwal,
thank you for your answer.

I’ll proceed with opening a ticket with STM (I’m currently using the latest available firmware), and try to add you as collaborator.

Regarding the event handling: in my implementation, the LE Read Remote Supported Features completion is used to drive the next step of my state machine. In practice, right after receiving it, I trigger the encryption procedure.

In the meantime, as a temporary workaround, if I intercept the Command Status event and detect that the Controller replies with Controller Busy, is there a safe way to retry the LE Read Remote Supported Features command?
Or would you recommend a different strategy to recover from this condition?

Thanks again for your support.

[mringwal]

Hi @TeoCarda

Unless there's an obvious/documented reason for the Controller to reject a command, it must not do that. Otherwise we would need to add logic to resend any of the hundreds of different HCI Commands which will increase the complexity by a magnitude..

You can trigger encryption upon GAP_SUBEVENT_LE_CONNECTION_COMPLETE. The stack is supposed to handle that correctly at a time it seems fit. Any reason to wait for response of LE Read Remote Supported Features?

Cheers
Matthias

[TeoCarda]

Hello,
I have an urgent activity which I need to look into. I'll come back to this topic in a few days.
Thank you

Br,
Matteo