Registering profile or making discoverable resets adapter class

Registering profile or making discoverable resets adapter class

[Serge van den Boom]

Hi,

When a new profile is registered, or an adapter is make discoverable,
the device class of the adapter is reset to the value set in
/etc/bluetooth/main.conf.

The test case below (to be run as root) demonstrates the issue. For this
demonstration, there should be no 'Class = ...' setting in
/etc/bluetooth/main.conf.


Regards,

Serge van den Boom


Output:
============================================================================
Registering signal receiver for property changes.
Starting main loop.
Making adapter '/org/bluez/hci0' non-discoverable.
Setting the Bluetooth device class to 0x000540 through hciconfig.
Class changed to 0x000540.
Registering profile.
Class changed to 0x100000.
Setting the Bluetooth device class to 0x000540 through hciconfig.
Class changed to 0x000540.
Making adapter '/org/bluez/hci0' discoverable.
Class changed to 0x100000.
Exiting.
============================================================================


The test case:
============================================================================
#!/usr/bin/env python3
import dbus.mainloop.glib
import logging
import subprocess
import time
from gi.repository import GLib
	
logging.basicConfig(format="%(message)s", level=logging.INFO)

DEVICE_CLASS = 0x000540
IFACE = "hci0"
ADAPTER = "/org/bluez/hci0"

def classChanged(interface, changed, invalidated):
	if 'Class' in changed:
		logging.info("Class changed to 0x{:06x}.".format(changed['Class']))

def step():
	logging.info("Making adapter '{}' non-discoverable.".format(ADAPTER))
	adapterProps = dbus.Interface(
			bus.get_object('org.bluez', ADAPTER), dbus.PROPERTIES_IFACE)
	adapterProps.Set('org.bluez.Adapter1', 'Discoverable', False)
	yield True

	logging.info("Setting the Bluetooth device class to 0x{:06x} through "
			"hciconfig.".format(DEVICE_CLASS))
	subprocess.call(["hciconfig", IFACE, "class", "0x{:06x}".format(DEVICE_CLASS)])
	yield True

	logging.info("Registering profile.".format(ADAPTER))
	profileManager = dbus.Interface(bus.get_object("org.bluez", "/org/bluez"),
			"org.bluez.ProfileManager1")
	profileManager.RegisterProfile("/org/example/test/profile",
			"00001124-0000-1000-8000-00805f9b34fb", {})
	yield True

	logging.info("Setting the Bluetooth device class to 0x{:06x} through "
			"hciconfig.".format(DEVICE_CLASS))
	subprocess.call(["hciconfig", IFACE, "class", "0x{:06x}".format(DEVICE_CLASS)])
	yield True

	logging.info("Making adapter '{}' discoverable.".format(ADAPTER))
	adapterProps = dbus.Interface(
			bus.get_object('org.bluez', ADAPTER), dbus.PROPERTIES_IFACE)
	adapterProps.Set('org.bluez.Adapter1', 'Discoverable', True)
	yield True

	logging.info("Exiting.")
	gMainLoop.quit()
	yield False

# Prepare the main loop for D-Bus.
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SystemBus()

# Listen for changes to the adapter class.
logging.info("Registering signal receiver for property changes.")
bus.add_signal_receiver(classChanged, bus_name="org.bluez",
		dbus_interface="org.freedesktop.DBus.Properties", path=ADAPTER,
		signal_name="PropertiesChanged")

# Schedule a step every second.
stepGenerator = step()
GLib.timeout_add(1000, lambda: next(stepGenerator))

# Go!
logging.info("Starting main loop.".format(ADAPTER))
gMainLoop = GLib.MainLoop()
gMainLoop.run()
============================================================================

Re: Registering profile or making discoverable resets adapter class

[Luiz Augusto von Dentz]

Hi Serge,

On Mon, Aug 1, 2016 at 3:34 PM, Serge van den Boom <serge@vdboom.org> wrote:
> Hi,
>
> When a new profile is registered, or an adapter is make discoverable,
> the device class of the adapter is reset to the value set in
> /etc/bluetooth/main.conf.
>
> The test case below (to be run as root) demonstrates the issue. For this
> demonstration, there should be no 'Class = ...' setting in
> /etc/bluetooth/main.conf.

This is a classical problem of using hci* tools along with bluetoothd,
they both are trying to control the same thing and then you got a
conflict, it shall be one or the other but not both. If you are
curious to look at the bluetoothd source code you will see that the we
derive the class of the device from the registered services so there
is no point in doing anything with hcitool.

Re: Registering profile or making discoverable resets adapter class

[Serge van den Boom]

Hi Luiz,

Thanks for the reply.

On Mon, 1 Aug 2016, Luiz Augusto von Dentz wrote:
> This is a classical problem of using hci* tools along with bluetoothd,
> they both are trying to control the same thing and then you got a
> conflict, it shall be one or the other but not both. If you are
> curious to look at the bluetoothd source code you will see that the we
> derive the class of the device from the registered services so there
> is no point in doing anything with hcitool.

That is interesting, because if I don't set the class explicitly, it
always shows up as 0x100000 when I inspect it. And more relevantly,
if I don't explicitly set the class, the (HID) device that I am
implementing won't be discovered.

I haven't been able to find the part of the bluetoothd code that you are
referring to, so far. I would appreciate it if you could point me in the
right direction.


Thanks,

Serge

Re: Registering profile or making discoverable resets adapter class

[Luiz Augusto von Dentz]

Hi Serge,

On Mon, Aug 1, 2016 at 7:12 PM, Serge van den Boom <serge@vdboom.org> wrote:
> Hi Luiz,
>
> Thanks for the reply.
>
> On Mon, 1 Aug 2016, Luiz Augusto von Dentz wrote:
>> This is a classical problem of using hci* tools along with bluetoothd,
>> they both are trying to control the same thing and then you got a
>> conflict, it shall be one or the other but not both. If you are
>> curious to look at the bluetoothd source code you will see that the we
>> derive the class of the device from the registered services so there
>> is no point in doing anything with hcitool.
>
> That is interesting, because if I don't set the class explicitly, it
> always shows up as 0x100000 when I inspect it. And more relevantly,
> if I don't explicitly set the class, the (HID) device that I am
> implementing won't be discovered.
>
> I haven't been able to find the part of the bluetoothd code that you are
> referring to, so far. I would appreciate it if you could point me in the
> right direction.

https://git.kernel.org/cgit/bluetooth/bluez.git/tree/src/adapter.c
(get_uuid_mask)

For more about registering profiles see:
https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/profile-api.txt

You may not be able to register HID as an external profile if the
input plugin is active because afaik both roles have to listen to
certain fixed PSMs, I wouldn't oppose to have this functionally in the
input plugin itself though since we can make it generic enough to use
with HoG implementation.


-- 
Luiz Augusto von Dentz

Re: Registering profile or making discoverable resets adapter class

[Serge van den Boom]

Hi Luiz,

On Mon, 1 Aug 2016, Luiz Augusto von Dentz wrote:

> On Mon, Aug 1, 2016 at 7:12 PM, Serge van den Boom <serge@vdboom.org> wrote:
> > I haven't been able to find the part of the bluetoothd code that you are
> > referring to, so far. I would appreciate it if you could point me in the
> > right direction.
> 
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/src/adapter.c
> (get_uuid_mask)

I see. So this only affects the major service class part of the
CoD field, and not the (major or minor) device class parts.
And as there is no case for HID_SVCLASS_ID, the CoD is not affected by
an HID service.

> For more about registering profiles see:
> https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc/profile-api.txt
> 
> You may not be able to register HID as an external profile if the
> input plugin is active because afaik both roles have to listen to
> certain fixed PSMs, I wouldn't oppose to have this functionally in the
> input plugin itself though since we can make it generic enough to use
> with HoG implementation.

I had my service working already, but it involved setting the class id
in the /etc/bluetooth/main.conf file. I disliked this, as it involved
making a system-wide modification to run my service.

After a conversation on the #bluez IRC channel, it appears that this
however is the correct way. Apparently, a bluetooth device is not
expected to change what it is.

I did indeed have to disable the input plugin.


Thanks,

Serge