Cannot conditionally disable pairing with bluetooth classic (bluedroid) (IDFGH-14491)

[vlang-intona]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

I'm testing pairing by connecting from a macOS computer to an ESP32 board, which implements an A2DP sink. I want the following pairing behavior:

• if a button (or similar condition) on the ESP32 board is pressed during the connection attempt, pairing should just work (no pin entry, just connecting)
• if the button is not pressed, only already bonded devices should be able to connect

For this, I would need to be able to programmatically change pair-ability at runtime with the "just works" method. But ESP32 does not seem to support this.

Running this at initialization makes pairing "just work":

esp_bt_sp_param_t param_type = ESP_BT_SP_IOCAP_MODE;
esp_bt_io_cap_t iocap = ESP_BT_IO_CAP_NONE;
esp_bt_gap_set_security_param(param_type, &iocap, sizeof(uint8_t));

This behavior is fine if the button is pressed. But if the button is not pressed, I need a way to reject not-yet-bonded devices.

Is this just a missing feature? I must have missed something obvious. At least I didn't find anything after spending a lot of time searching the documentation and the internet (where I only found people with the same problem).

I tried working this around by changing it do ESP_BT_IO_CAP_IO at runtime, which would effectively force pin entry. Then I rejected the attempt in the ESP_BT_GAP_CFM_REQ_EVT handler. But this does not seem to allow already bonded devices to connect anyway. (Either ESP32 rejected this because of the settings change, or I made a mistake. But even if it worked, this isn't an ideal solution.)

My next hack idea would be to disconnect the device in response to ESP_BT_GAP_AUTH_CMPL_EVT, which would be even hackier and extremely questionable in multiple ways, but at least it would get the job done.

I'm also confused that this document talks about the device with the yes/no button, but there's no explanation how to achieve it, and instead goes on about things irrelevant to the ESP32 API user:

https://github.com/espressif/esp-idf/blob/master/examples/bluetooth/bluedroid/classic_bt/bt_spp_acceptor/ESP32_SSP.md

[ESP-YTGerd]

Hi, @vlang-intona
The purpose of IO capability setting is to determine the authentication algorithm used in the Authentication stage 1
phase of Secure Simple Pairing. If you set the IO capability of ESP32 as ESP_BT_IO_CAP_IO(DisplayYesNo) and your macOS also supports DisplayYesNo, the pairing method should be Numeric Comparison based on the documentation above ESP32_SSP . This means that a pop-up window will appear on the computer, displaying a "Yes" or "No" option along with a number that you need to compare. On the ESP32 side, the corresponding pop-up is represented by the ESP_BT_GAP_CFM_REQ_EVT event, where the parameter cfm_req.num_val contains the number that needs to be compared.

In the a2dp_sink example, we automatically call the API esp_bt_gap_ssp_confirm_reply to confirm the number to be compared. This process is equivalent to pressing the "Yes" button.

Going back to your question, setting the ESP32's IO capability to ESP_BT_IO_CAP_IO consistently can actually meet your requirements. When the ESP_BT_GAP_CFM_REQ_EVT event is triggered, you can check the state of your button to determine whether it's a "Yes" or "No". If it's "Yes", you can directly call the API esp_bt_gap_ssp_confirm_reply to confirm the pairing. If it's "No," you can use the same API to reject the pairing. This works because, in this scenario, already bonded devices will skip the pairing process and connect directly, while only new devices will trigger the ESP_BT_GAP_CFM_REQ_EVT event. Additionally, it's worth noting that, regardless of the pairing method, already bonded devices will always connect directly without going through the pairing process again.

Let me know if you need further clarification!

[vlang-intona]

Going back to your question, setting the ESP32's IO capability to ESP_BT_IO_CAP_IO consistently can actually meet your requirements. When the ESP_BT_GAP_CFM_REQ_EVT event is triggered, you can check the state of your button to determine whether it's a "Yes" or "No". If it's "Yes", you can directly call the API esp_bt_gap_ssp_confirm_reply to confirm the pairing. If it's "No," you can use the same API to reject the pairing. This works because, in this scenario, already bonded devices will skip the pairing process and connect directly, while only new devices will trigger the ESP_BT_GAP_CFM_REQ_EVT event.

Yes, but it will show an actual popup on macOS, which usually disappears immediately. Sometimes (under circumstances which are unclear to me) it even requires me to click a button to allow the connection. Similar things happen on other OSes. I wanted to avoid that.

Additionally, it's worth noting that, regardless of the pairing method, already bonded devices will always connect directly without going through the pairing process again.

That part works well in any of the modes.

Let me know if you need further clarification!

Are there no plans to enable the framework user to hook into authentication and to make the BT stack send a LMP_NOT_ACCEPTED message according to the bluetooth spec Vol 2 Part C 4.2.2.3 ("Responder rejects pairing")?

[ESP-YTGerd]

@vlang-intona,
Currently, we don’t have a specific HCI command to reject this LMP request, so it’s also not possible to directly reject it at the application level.

Additionally, could I confirm your requirements? Is it because you want to avoid the pop-up window on macOS, so you have to set the ESP32’s IO capability to No Input No Output, which forces the pairing method to be Just Works? However, this approach doesn’t allow flexible control over pairing with new devices, right?

[vlang-intona]

Additionally, could I confirm your requirements? Is it because you want to avoid the pop-up window on macOS, so you have to set the ESP32’s IO capability to No Input No Output, which forces the pairing method to be Just Works?

Correct. Pairing is supposed to be enabled on the device with a button. While pairing is enabled, anyone should be able to connect without needing to enter pins or any other type of confirmation.

However, this approach doesn’t allow flexible control over pairing with new devices, right?

Our problem is that pairing (in this mode) can't be disabled on the IDF API level.

[ESP-YTGerd]

Additionally, could I confirm your requirements? Is it because you want to avoid the pop-up window on macOS, so you have to set the ESP32’s IO capability to No Input No Output, which forces the pairing method to be Just Works?

Correct. Pairing is supposed to be enabled on the device with a button. While pairing is enabled, anyone should be able to connect without needing to enter pins or any other type of confirmation.

However, this approach doesn’t allow flexible control over pairing with new devices, right?

Our problem is that pairing (in this mode) can't be disabled on the IDF API level.

Currently, the Bluedroid framework does not support disabling pairing at the API level. A somewhat tricky workaround, as you mentioned earlier, is to directly reject the pairing when the ESP_BT_GAP_CFM_REQ_EVT event is triggered if the button is not pressed.
Another feasible approach is to directly reject the ACL connection requests from devices that are not in the bond list when the button is not pressed. However, we also do not provide an interface at the application layer to determine whether to accept the connection request from the peer device.