Hi Luiz, The Device ID setting in the main.conf only sets the PnP ID Characteristic under the DIS. My service was providing other characteristics (Manufacturer Name [2A29] & Firmware Revision [2A26]) which aren't settable with that configuration variable. So it'd be how would I set the above characteristics? If this service isn't suitable to be used then that is fine if it comes to it as I can go back to the App developers and say that it won't be suitable to use, but unfortunately so far they're just recommending that we keep with an older version of BlueZ where this issue doesn't occur. On Fri, Mar 5, 2021 at 4:04 PM Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > > Hi Ryan, > > On Fri, Mar 5, 2021 at 2:01 AM Ryan Walmsley <ryan@xxxxxxxxxxxxx> wrote: > > > > So is it possible for me to set the above values I require in main.conf? > > > > There's no documentation showing that it's possible to set the values > > in main.conf. > > https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/src/main.conf#n30 > > Or are you saying this is not enough and more fields need to be added? > > > If not then I think that surely the override to disable the service > > being provided by BlueZ needs to be added? > > > > At the time the code was added it was even picked up that it would > > break operationality and suggested a kill switch to be added, but now > > I'm reporting it as a bug it's not going to be added? > > Well even with the kill switch for the daemon not to add another > instance of DIS the problem doesn't go away because then any other > application can register DIS as well, in fact we may need to put some > code together to stop registering multiple instances of services that > don't support such thing. Anyway if you have programmed the values on > main.conf, which is shared with classic, failing to register DIS > should have no impact. > > > > > On Thu, Mar 4, 2021 at 8:07 PM Ryan Walmsley <ryan@xxxxxxxxxxxxx> wrote: > > > > > > 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 > > > > > > > > -- > > > > 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 > > > > -- > 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
