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.

[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.

[Andy]

That is a usual misconception. Authorization and authentication are different concepts. Authorized reads and writes just allow the application to do whatever before the data is read or written. Authentication has to do with security. These terms are not used interchangeably.

[brianreinhold]

Andy, thanks for that. I did some extensive googling and looking through the BT spec 5.0 (didn't find much there) but did find that authorization is application-specific; in other words the only thing the client knows about the characteristic is that it is readable. That is good. Here is a good link on that which states it in clear text: http://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_1_40_00_45/docs/blestack/ble_user_guide/html/ble-stack-3.x/gatt.html

I do NOT want to use the read with authorization option to authorize but to catch the client read and set the value they are going to get in the response at the time of the read. It would be a twisted way to do that but it seems many BLE chip developers don't understand that a peripheral may have some readable characteristic that changes frequently but the client may only need to access it's value infrequently. Who wants to frequently update the characteristic data base (perhaps 100s of times per second) when the client may never need to read it or only needs to read it once and a while?

For example, I had an activity monitor following the IEEE 11073 20601 cardio specialization using a relative time clock. Relative time clocks are easy to implement as they are only a sequence of ticks. One of the characteristics in this activity monitor service was the current relative time in milliseconds. All the measurements taken reported a time stamp using this relative time clock. The client, however, needs to turn this relative time into a wall clock time. It does so by reading the current relative time characteristic and looking at its current wall clock time. Then it can convert all relative time stamps in the measurements (in the future and the past) to wall clock time. But the client only needs to read the current time once per connection. When that read happens is not known. So if I can catch the read, I can set the characteristic to the current time. If one CANT catch the read, one has to update the characteristic value in the database 1000 times a second. Are you kidding??!!! But if the read with authorization allows me to pull this off, I am good!

Even the Android BLE server API allows catching ordinary reads.