Preventing Services From Being Discovered

RE: Preventing Services From Being Discovered

Hung Bui — Wed, 22 Apr 2015 13:43:15 GMT

@Cory: I agree with what Ulrich explained. Just want to attach here an example of how to update the attribute table on the fly and send service changed indication. In the example (SDK v6.1) I add the battery level service 20 seconds after connected.

ble_app_hrs - ServiceChangedBond.zip

RE: Preventing Services From Being Discovered

Ulrich Myhre — Wed, 22 Apr 2015 11:22:57 GMT

Hi Cory,

Unfortunately, the thing you are asking for is not allowed per the Bluetooth spec. All declarations have to be readable and not require authentication or authorization, and this is mentioned for services, includes and characteristics alike. So disallowing enumeration is not allowed. Additionally, blocking enumeration will not block peers from reading and writing to arbitrary handles.

The only possible way I see for you to accomplish what you are requesting is to actually create the database after the authentication is successful. You are then, as shibshab mentions, required to include the service changed characteristic. This lets you notify the peer that you did indeed change your database so it can rediscover it. Changing the database on the fly without service changed is also against the spec, so thread carefully!

The Nike Fuel Band has implemented its own protocol over two characteristic in its database (which is fully discoverable), and basically re-implement a subset of GATT through sending commands to one of the characteristics and receiving data from the other one. This is also possible with Nordic SoftDevices that implement BLE, but we do not have any examples that do this.

RE: Preventing Services From Being Discovered

shibshab — Wed, 22 Apr 2015 07:34:19 GMT

When initializing the softdevice, have you set the service change bit to '1' ? This is required for the functionality you are describing at least.

This is the service_changed property of ble_enable_params.gatts_enable_params