Notifications and CCC descriptor handling for Gatt server
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
Luiz Augusto von Dentz
maintainerHi Andrejs,
Quoted 5 lines · 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?
This is probably a bug, bluetoothd shall only call StartNotification once, it shall also call StopNotification if there no client connected.
Quoted 1 line
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.
Quoted 1 line
4. Client B connects and disables notifications, StopNotify is called.
That is probably fine, it both StartNotify and StopNotify shall only be called once.
Quoted 8 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Luiz Augusto von Dentz
Hi,
Quoted 5 lines · Luiz Augusto von Dentz
Hi Andrejs,
Quoted 2 lines · Andrejs Hanins
Hi,
Quoted 7 lines
Quoted 3 lines
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?
Quoted 21 lines
Quoted 2 lines
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.
Quoted 1 line
4. Client B connects and disables notifications, StopNotify is called.
That is probably fine, it both StartNotify and StopNotify shall only be called once.
Quoted 8 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html