Hi Bruno, On Tue, Oct 1, 2019 at 8:06 PM Bruno Randolf <br1@xxxxxxxxxxx> wrote: > > Hello All, > > I am a developer using bluez via D-Bus to access GATT services and > characteristics [1] and I would like to argue that bluez should not > filter UUIDs of characteristics it handles by internal plugins. Well I guess you are forgetting that other users of the GATT may interfere with plugin which is why we do the claim APIs in the first place. > I recently came across this with the battery service (BAS). Our BLE > device exports it, I can read it on Android, iOS and from other devices, > but reading it from Linux is impossible. The UUID doesn't even show up > in the list of characteristics! It took me a while to figure out, that > it is filtered out and that you are supposed to read it via a different > API on D-Bus [2]. Reading is done automatically if the plugin is enabled, you can disable the plugin if you don want it to be automatically read, having both will not gonna happen since it will incur in more traffic in this case and may have security implication in services such as HoG. > It surely makes sense to provide this more generic API, but I'd argue > that all services and characteristics should be available via the normal > GATT-based API using org.bluez.GattCharacteristic1 as well. Not if the service has security implication, for instance we don't want application to be able to access the keys presses coming from a HoG device, or other things like changing the settings bluetoothd has configured. > One of my clients, for example, uses Linux/bluez as an interface for > Server-based reading and writing of GATT characteristics of several > managed devices. So I can read all those UUIDs, but why not the battery > level? What happens when Bluez learns other GATT services, will their > characteristics then also disappear? I think there is a strong argument > for maintaining a generic API for GATT reading/writing characteristics > independently. But there is even a stronger argument if something breaks because the app access something it shouldn't, even if there are no conflicts between the plugin the very least it would cause is duplicating the traffic. > I made the following change to the bluetoothd code to get access again > to all UUIDs, and I would like you to consider to include it upstream to > enable us to access all characteristics via the normal GATT API: > > --- a/src/gatt-client.c > +++ b/src/gatt-client.c > @@ -2006,9 +2006,6 @@ static void export_service(struct > gatt_db_attribute *attr, void *user_data) > struct btd_gatt_client *client = user_data; > struct service *service; > > - if (gatt_db_service_get_claimed(attr)) > - return; > - > service = service_create(attr, client); > if (!service) > return; > > Thank you, > bruno > > > [1] I published parts of that as an open source library: > https://github.com/infsoft-locaware/blzlib > > [2] > https://stackoverflow.com/questions/49078659/check-battery-level-of-connected-bluetooth-device-on-linux > > -- Luiz Augusto von Dentz
