Hi Luiz, Thanks for the response. We use our program to set characteristics 2A29 (Manufacturer Name), 2A26 (Firmware) and 2A25 (Serial Number) under the 180A service. I can't see where in main.conf I can set these variables. However for our use case this wouldn't really be a suitable method as we have the software running in docker containers communicating with bluez on the host via dbus. Setting the above values in main.conf would require more than just the containers to be updated each time we bump a new firmware version. I have tried removing the service before we add outs using the "unregister-service 0x0000180a-0000-1000-8000-00805f9b34f" feature in bluetoothctl but just get a failed to unregister service issue. While it might not be the ideal way to do it this way where we create the service, however if it was flagged at the time of commit that enabled BlueZ to provide this service that it could cause stuff to break then surely it's more an issue with BlueZ and the suggested override should be added? On Thu, Mar 4, 2021 at 7:36 PM Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > > Hi Ryan, > > On Thu, Mar 4, 2021 at 11:10 AM Ryan Walmsley <ryan@xxxxxxxxxxxxx> wrote: > > > > Hi, > > > > We've been working on something that uses Bluetooth to provide GATT > > services and recently have updated to BlueZ 5.55 from 5.53 and have > > found an issue. > > > > It seems that in the newer version a commit was made > > (d5e07945c4aa36a83addc3c269f55c720c28afdb) that enabled the service > > 0x180A with characteristic 0x2A50. > > Yep, DIS is controlled by the daemon since you can set the vendor, > product and version using main.conf. > > > However as our software creates a service on 0x180A it causes a > > conflict, as the application we are making our software with reads > > from the first service available which is the one generated by BlueZ. > > You should probably stop doing that and just use main.conf to set the > values you want to be published, we should actually blacklist DIS to > be registered by applications since that is defined by the platform > having the application to override may actually cause problems. > > > It looks like it was discussed about a kill switch being added of > > "DeviceIdOverLE" to then disable this but I can't find any reference > > to this at all. > > > > How would be best to disable this? > > Disable DIS on the application, you can actually check if the adapter > has enabled it already using its UUIDs: > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/adapter-api.txt#n321 > > bluetoothctl also can be use to print the list of UUIDs that the > adapter is exposing (0000180a-0000-1000-8000-00805f9b34fb is DIS): > > [bluetooth]# show > Controller 00:AA:01:01:00:24 (public) > Name: > Alias: > Class: 0x00000000 > Powered: no > Discoverable: no > DiscoverableTimeout: 0x000000b4 > Pairable: yes > UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb) > UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) > UUID: OBEX Object Push (00001105-0000-1000-8000-00805f9b34fb) > UUID: Message Access Server (00001132-0000-1000-8000-00805f9b34fb) > UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) > UUID: IrMC Sync (00001104-0000-1000-8000-00805f9b34fb) > UUID: Headset (00001108-0000-1000-8000-00805f9b34fb) > UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) > UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) > UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb) > UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb) > UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb) > UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) > UUID: Headset AG (00001112-0000-1000-8000-00805f9b34fb) > UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb) > UUID: OBEX File Transfer (00001106-0000-1000-8000-00805f9b34fb) > Modalias: usb:v1D6Bp0246d0538 > Discovering: no > Roles: central > Roles: peripheral > Advertising Features: > ActiveInstances: 0x00 (0) > SupportedInstances: 0x01 (1) > SupportedIncludes: tx-power > SupportedIncludes: appearance > SupportedIncludes: local-name > SupportedSecondaryChannels: 1M > SupportedSecondaryChannels: 2M > SupportedSecondaryChannels: Coded > > > -- > > Ryan Walmsley > > > > Engineer > > > > Pi Supply Unit 4 Bells Yew Green Business Court, > > Bells Yew Green, East Sussex, TN3 9BJ, United Kingdom > > > > -- > Luiz Augusto von Dentz -- Ryan Walmsley Engineer Pi Supply Unit 4 Bells Yew Green Business Court, Bells Yew Green, East Sussex, TN3 9BJ, United Kingdom Email us at sales@xxxxxxxxxxxxx
