Is a GATT server application notified of a client read?

[brianreinhold]

I looked at the following question

nrRF2 GATT attribute read callback

and it does not quite answer what I want to know.

What I need to know is do I get signaled by the nrRF2* BLE hardware when a client attempts to read a characteristic such that I can populate that characteristic with some data that I want the client to receive as a result of the read?  For example, the high level Android server has such an event - but the Renesas RL78 BLE chip does not.

The original question had a yes answer with an 'authorized' read. I am not sure if 'authorized' is a BLE thing or a Nordic thing in this context. I do not want to have to configure the read characteristic to be secured or anything special. The characteristic should only need read permission.

I was looking though the SoftDevice API and did not see any GATT event for a generic client read.  I did see the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST event noted above but I do not really understand that. To be fair, I have just started looking at the nrRF2* and the pc-ble-driver and supporting systems as a possible use for a BLE client test suite (thus the need to have the application run on the PC using the BLE functionality on the nrRF2*). However, it is critical that the application get signaled that a client attempted to read any readable characteristic so its value can be set (and 'sent') to the client.

I would like to know if it is possible to get evented of a generic read (I assumed it was) because if it is not, all I will lose at this time is the $30 I spent on getting a few test dongles which have not yet arrived.

[brianreinhold]

I was looking at some other API documentation of SoftDevice (can't find it now). From the wording there I got the impression that the word 'authorize' in the event name had nothing to do with the security settings meaning of the word. It looked like it simply meant the characteristic had read permissions. 

Thus I have much more confidence that my peripheral application will be notified when the client tries to read ANY characteristic that has read permissions regardless of its security settings. The application can then set the characteristic value that the client will receive in the read response. Please vindicate that this is true!

A re-read of the SoftDevice API elsewhere sounds like this event is just for the peripheral to set the permissions of the characteristic.

Now it strongly looks like my peripheral application will NOT be signaled of a client read.

[Hung Bui]

Hi Brian, 

Your understanding (in your reply) is correct. I would suggest to look at the message sequence chart when you are unsure about something. The read with authorization is described here.

A characteristic with read authorization property set to 0 will not get an event when there is a read. Only those characteristic with the read authorization set to 1 will get an event. And you need to reply before the softdevice can send the read response. 

The Bluetooth spec doesn't define how exactly the read authorization should be, but it does mention a bit about it at section 3.4.4.3 Part F Vol 3 Bluetooth Core spec v5.1 : 

If the attribute value cannot be read due to permissions then an Error Response shall be sent with the error code Read Not Permitted.

The connection security authorization is something different (with error code: Insufficient Authorization.) 

Btw, what is nRF2 or nRF2* ? I guess you meant nRF52 ? 

[brianreinhold]

So just to be absolutely clear:

If I create a service that has a characteristic with permission read and a default value;

When the client reads it I WILL get an event and I can at the time of the event change that default value (or do something) such that the client gets the new value in the read response. 

If I can do that for any characteristic that has read permission then I am happy. I hope so as I have already ordered some trial dongles!

[Hung Bui]

Yes what you described is possible on any characteristic, but only if you configure the characteristic with read with authorization (rd_auth = 1 in the attribute metadata or is_defered_read = 1 if you configure the characteristic via ble_srv_common.c ) . 

I'm not sure which dongle you are talking about, but for development we suggest you to get started with nRF52 Development Kit. 

[brianreinhold]

I am starting with the nRF52 dongle. The development kit is for running applications (eventually) on the nRF52 module. I only want to use the module for the BLE 'radio'. The application needs to sit on the PC as it will demand far more resources than could sit on the module (including the ability to communicate with remote servers).

I am assuming, then, that when I configure the characteristic with 'read with authorization' that the client sees this as a characteristic with ordinary 'read permission' with no other conditions and will NOT have to engage in any extra procedures than just connecting to read the characteristic. 

I have to say this is confusing since in the Bluetooth standard I see a read with authorization and that IS security.A client has to be authorized before being able to read - MITM.

This is critical. I want to be sure that if I make a DIS whose characteristics a client can read with NO encryption or any other extra security procedures that my server application can be signaled when that client reads one of the characteristics.