Notifications and CCC descriptor handling for Gatt server

Notifications and CCC descriptor handling for Gatt server

[Andrejs Hanins]

Hi,

	I have a Gatt server over D-Bus with "notify" characteristic exported and I listen to Start/StopNotify methods. But I can't get my head around the logic of Start/StopNotify methods in case of multiple Gatt clients connecting to the service (not in the same time, of course):
	1. Client A connects and enables notifications, StartNotify is called - this is fine.
	2. Client B connects and enables notifications, then StartNotify is called again - is it expected? Does it mean notifications state is per-client and external Gatt server needs to know the currently connected client and associate some state with it?
	3. Client A connects again and disables notifications, StopNotify is not called. This is strange and goes against the logic in item 2.
	4. Client B connects and disables notifications, StopNotify is called.

	So, how is it supposed to work? Maybe there is a bug somewhere?
	BlueZ 5.32 used.

BR, Andrey

Re: Notifications and CCC descriptor handling for Gatt server

[Luiz Augusto von Dentz]

Hi Andrejs,

On Fri, Aug 7, 2015 at 12:31 AM, Andrejs Hanins <andrejs.hanins@ubnt.com> wrote:
> Hi,
>
>         I have a Gatt server over D-Bus with "notify" characteristic exported and I listen to Start/StopNotify methods. But I can't get my head around the logic of Start/StopNotify methods in case of multiple Gatt clients connecting to the service (not in the same time, of course):
>         1. Client A connects and enables notifications, StartNotify is called - this is fine.
>         2. Client B connects and enables notifications, then StartNotify is called again - is it expected? Does it mean notifications state is per-client and external Gatt server needs to know the currently connected client and associate some state with it?

This is probably a bug, bluetoothd shall only call StartNotification
once, it shall also call StopNotification if there no client
connected.

>         3. Client A connects again and disables notifications, StopNotify is not called. This is strange and goes against the logic in item 2.

It shall only call StopNotify if it is the last client, otherwise this is ok.

>         4. Client B connects and disables notifications, StopNotify is called.

That is probably fine, it both StartNotify and StopNotify shall only
be called once.

>         So, how is it supposed to work? Maybe there is a bug somewhere?
>         BlueZ 5.32 used.
>
> BR, Andrey
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Luiz Augusto von Dentz

Re: Notifications and CCC descriptor handling for Gatt server

[Andrejs Hanins]

Hi,

On 08/09/2015 06:13 PM, Luiz Augusto von Dentz wrote:
> Hi Andrejs,
> 
> On Fri, Aug 7, 2015 at 12:31 AM, Andrejs Hanins <andrejs.hanins@ubnt.com> wrote:
>> Hi,
>>
>>         I have a Gatt server over D-Bus with "notify" characteristic exported and I listen to Start/StopNotify methods. But I can't get my head around the logic of Start/StopNotify methods in case of multiple Gatt clients connecting to the service (not in the same time, of course):
>>         1. Client A connects and enables notifications, StartNotify is called - this is fine.
>>         2. Client B connects and enables notifications, then StartNotify is called again - is it expected? Does it mean notifications state is per-client and external Gatt server needs to know the currently connected client and associate some state with it?
> 
> This is probably a bug, bluetoothd shall only call StartNotification
> once, it shall also call StopNotification if there no client
> connected.
So, should I create a bug report?
> 
>>         3. Client A connects again and disables notifications, StopNotify is not called. This is strange and goes against the logic in item 2.
> 
> It shall only call StopNotify if it is the last client, otherwise this is ok.
> 
>>         4. Client B connects and disables notifications, StopNotify is called.
> 
> That is probably fine, it both StartNotify and StopNotify shall only
> be called once.
> 
>>         So, how is it supposed to work? Maybe there is a bug somewhere?
>>         BlueZ 5.32 used.
>>
>> BR, Andrey
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
>