Can a GATT server refuse a connection?

[maldus]

Hello everyone,
I'm trying to implement a pairing protocol in my BLE GATT server. I have a device with a display that should ask the user whether the requesting client (a smartphone) is authorized before accepting to share informations.

I based my program on the GATT server example; as far as I understand once I receive the ESP_GATTS_CONNECT_EVT the connection is already established, and there is no way to "hold it off" until a confirmation is given. Am I correct?

In this case I could simply remember the connection status and refuse all requests until it is confirmed by the user (using ESP_GATT_READ_NOT_PERMIT and ESP_GATT_WRITE_NOT_PERMIT status codes). I am not a bluetooth expert so I'm asking if this is a optimal (or evend decent) solution or if I'm overlooking a more obvious choice.

[chegewara]

There is few possible ways to protect server with authorization/authentication. One way is that you are proposing. In this approach you just have to setup every characteristic and descriptor that you wish to protect (some of it can be read/write without authentication) with ESP_GATT_PERM_READ_ENCRYPTED and/or ESP_GATT_PERM_WRITE_ENCRYPTED.

The other one is to request authentication with or without pin code during connecting. This way attributes cant be enumerated. This requires to call esp_ble_set_encryption in ESP_GATTS_CONNECT_EVT or ESP_GATTC_CONNECT_EVT event.

Here you have nice written documents:
https://github.com/espressif/esp-idf/bl ... through.md

https://github.com/espressif/esp-idf/bl ... through.md

[maldus]

Many thanks for answering me.

I was aware of the possibility to use encryption to authenticate the client. However, I am not interested in hiding the informations that are communicated, only in ensuring that my device does not accept commands from unauthorized clients.

I want to avoid encryption if possible since it will probably add a lot of complexity to my code. Anyway, I'll study the secure server tutorial an see for myself which one is the better option.