Powered property and rfkill

Powered property and rfkill

[Bastien Nocera]

Hey,

I was wondering the reasoning behind the recent changes in rfkill
handling for hci interfaces, in particular the addition
of MGMT_STATUS_RFKILLED as an error message.

Before those changes (for which I couldn't find an initial kernel side
commit), the Powered state of the adapter was tied to its rfkill
status.

When a soft rfkilled device showed up, which was to be the default
adapter, bluetoothd would remember that it was powered, and unrfkill
it. If the state was unpowered, or it had been rfkilled, GNOME's
Bluetooth panel would set Powered to true, un-rfkill'ing the adapter.

In 99% of cases, this meant that plugging in a Bluetooth adapter would
work out of the box.

Now, bluetoothd doesn't remember the power state, and the rfkill isn't
tied to the Powered state. Calling to set the Power state will fail
with the "Blocked" error, and we're expecting something else to unset
the adapter's rfkill status.

What did the developers making those changes hope that would unrfkill
and power up the adapter when plugged in?

Note that this might be a side-effect of the machine I'm using which
has 2 layers of Bluetooth rfkill:
$ rfkill list bluetooth
0: tpacpi_bluetooth_sw: Bluetooth
	Soft blocked: no
	Hard blocked: no
4: hci0: Bluetooth
	Soft blocked: yes
	Hard blocked: no

hci0 won't be visible if tpacpi_bluetooth_sw is soft-killed. The work-
around I have planned is to wait for "hci*" to appear if the Bluetooth
rfkill we unset doesn't start with "hci".

Any better ideas?

Cheers

Re: Powered property and rfkill

[Marcel Holtmann]

Hi Bastien,

> I was wondering the reasoning behind the recent changes in rfkill
> handling for hci interfaces, in particular the addition
> of MGMT_STATUS_RFKILLED as an error message.
> 
> Before those changes (for which I couldn't find an initial kernel side
> commit), the Powered state of the adapter was tied to its rfkill
> status.

actually RFKILL was never tied to the controller's power state. Neither via mgmt nor via the old legacy ioctl that do the hciconfig hci0 up. We also have an ERFKILL errno error code introduced for RFKILL a long time ago. It is a special error code that you would get when trying to hciconfig hci0 up or even ifconfig wlan0 up (in case of WiFi).

RFKILL does two things, a) force an interface down in case it is up and you RFKILL block it, b) return an error when you try to bring up a blocked interface.

It always worked this way. The MGMT_STATUS_RFKILLED is just the mgmt error status equivalent of ERFKILL.

> When a soft rfkilled device showed up, which was to be the default
> adapter, bluetoothd would remember that it was powered, and unrfkill
> it. If the state was unpowered, or it had been rfkilled, GNOME's
> Bluetooth panel would set Powered to true, un-rfkill'ing the adapter.

I do not remember that automatic un-rfkilling from within bluetoothd. Maybe Johan and Luiz remember something in this area.

> In 99% of cases, this meant that plugging in a Bluetooth adapter would
> work out of the box.
> 
> Now, bluetoothd doesn't remember the power state, and the rfkill isn't
> tied to the Powered state. Calling to set the Power state will fail
> with the "Blocked" error, and we're expecting something else to unset
> the adapter's rfkill status.

My feeling is that you are running into the case where something changed in the RFKILL subsystem or how systemd started to interact with RFKILL. I have seen the cases where it boots up with a soft-blocked state, but I never really tried to analyze the case.

The automatic power and remembering of powered state has been removed since BlueZ 5.0, but recently we have introduced the AutoEnable main.conf option in case you prefer to always power on your adapters during early boot. This helps for cases where Bluetooth needs to be up before an user logged in, but it also means that no agent is available. So choose that option wisely.

> What did the developers making those changes hope that would unrfkill
> and power up the adapter when plugged in?
> 
> Note that this might be a side-effect of the machine I'm using which
> has 2 layers of Bluetooth rfkill:
> $ rfkill list bluetooth
> 0: tpacpi_bluetooth_sw: Bluetooth
> 	Soft blocked: no
> 	Hard blocked: no
> 4: hci0: Bluetooth
> 	Soft blocked: yes
> 	Hard blocked: no
> 
> hci0 won't be visible if tpacpi_bluetooth_sw is soft-killed. The work-
> around I have planned is to wait for "hci*" to appear if the Bluetooth
> rfkill we unset doesn't start with "chi".

That is the Thinkpad specific platform RFKILL switch that kills the power to the USB device. Some platforms have this switches. They are owned by the platform or ACPI. The hci0 is the one represented by the Bluetooth subsystem.

Regards

Marcel

Re: Powered property and rfkill

[Bastien Nocera]

On Mon, 2016-01-04 at 10:11 -0800, Marcel Holtmann wrote:
> Hi Bastien,
> 
> > I was wondering the reasoning behind the recent changes in rfkill
> > handling for hci interfaces, in particular the addition
> > of MGMT_STATUS_RFKILLED as an error message.
> > 
> > Before those changes (for which I couldn't find an initial kernel
> > side
> > commit), the Powered state of the adapter was tied to its rfkill
> > status.
> 
> actually RFKILL was never tied to the controller's power state.
> Neither via mgmt nor via the old legacy ioctl that do the hciconfig
> hci0 up. We also have an ERFKILL errno error code introduced for
> RFKILL a long time ago. It is a special error code that you would get
> when trying to hciconfig hci0 up or even ifconfig wlan0 up (in case
> of WiFi).
> 
> RFKILL does two things, a) force an interface down in case it is up
> and you RFKILL block it, b) return an error when you try to bring up
> a blocked interface.
> 
> It always worked this way. The MGMT_STATUS_RFKILLED is just the mgmt
> error status equivalent of ERFKILL.

OK.

> > When a soft rfkilled device showed up, which was to be the default
> > adapter, bluetoothd would remember that it was powered, and
> > unrfkill
> > it. If the state was unpowered, or it had been rfkilled, GNOME's
> > Bluetooth panel would set Powered to true, un-rfkill'ing the
> > adapter.
> 
> I do not remember that automatic un-rfkilling from within bluetoothd.
> Maybe Johan and Luiz remember something in this area.
> 
> > In 99% of cases, this meant that plugging in a Bluetooth adapter
> > would
> > work out of the box.
> > 
> > Now, bluetoothd doesn't remember the power state, and the rfkill
> > isn't
> > tied to the Powered state. Calling to set the Power state will fail
> > with the "Blocked" error, and we're expecting something else to
> > unset
> > the adapter's rfkill status.
> 
> My feeling is that you are running into the case where something
> changed in the RFKILL subsystem or how systemd started to interact
> with RFKILL. I have seen the cases where it boots up with a soft-
> blocked state, but I never really tried to analyze the case.

That's a more likely problem, yes. Removing the Bluetooth files
in /var/lib/systemd/rfkill/*:bluetooth seems to solve the problem.

I'll still need to find a way to avoid those inconsistent state
problems.

> The automatic power and remembering of powered state has been removed
> since BlueZ 5.0, but recently we have introduced the AutoEnable
> main.conf option in case you prefer to always power on your adapters
> during early boot. This helps for cases where Bluetooth needs to be
> up before an user logged in, but it also means that no agent is
> available. So choose that option wisely.

I was wondering whether changes around this were responsible for the
problem.

> > What did the developers making those changes hope that would
> > unrfkill
> > and power up the adapter when plugged in?
> > 
> > Note that this might be a side-effect of the machine I'm using
> > which
> > has 2 layers of Bluetooth rfkill:
> > $ rfkill list bluetooth
> > 0: tpacpi_bluetooth_sw: Bluetooth
> > 	Soft blocked: no
> > 	Hard blocked: no
> > 4: hci0: Bluetooth
> > 	Soft blocked: yes
> > 	Hard blocked: no
> > 
> > hci0 won't be visible if tpacpi_bluetooth_sw is soft-killed. The
> > work-
> > around I have planned is to wait for "hci*" to appear if the
> > Bluetooth
> > rfkill we unset doesn't start with "chi".
> 
> That is the Thinkpad specific platform RFKILL switch that kills the
> power to the USB device. Some platforms have this switches. They are
> owned by the platform or ACPI. The hci0 is the one represented by the
> Bluetooth subsystem.

Right, knew that, but was wondering whether the layering of rfkills, in
addition to other changes, might have been the reason why this broke.

Cheers

Re: Powered property and rfkill

[Marcel Holtmann]

Hi Bastien,

>>> I was wondering the reasoning behind the recent changes in rfkill
>>> handling for hci interfaces, in particular the addition
>>> of MGMT_STATUS_RFKILLED as an error message.
>>> 
>>> Before those changes (for which I couldn't find an initial kernel
>>> side
>>> commit), the Powered state of the adapter was tied to its rfkill
>>> status.
>> 
>> actually RFKILL was never tied to the controller's power state.
>> Neither via mgmt nor via the old legacy ioctl that do the hciconfig
>> hci0 up. We also have an ERFKILL errno error code introduced for
>> RFKILL a long time ago. It is a special error code that you would get
>> when trying to hciconfig hci0 up or even ifconfig wlan0 up (in case
>> of WiFi).
>> 
>> RFKILL does two things, a) force an interface down in case it is up
>> and you RFKILL block it, b) return an error when you try to bring up
>> a blocked interface.
>> 
>> It always worked this way. The MGMT_STATUS_RFKILLED is just the mgmt
>> error status equivalent of ERFKILL.
> 
> OK.
> 
>>> When a soft rfkilled device showed up, which was to be the default
>>> adapter, bluetoothd would remember that it was powered, and
>>> unrfkill
>>> it. If the state was unpowered, or it had been rfkilled, GNOME's
>>> Bluetooth panel would set Powered to true, un-rfkill'ing the
>>> adapter.
>> 
>> I do not remember that automatic un-rfkilling from within bluetoothd.
>> Maybe Johan and Luiz remember something in this area.
>> 
>>> In 99% of cases, this meant that plugging in a Bluetooth adapter
>>> would
>>> work out of the box.
>>> 
>>> Now, bluetoothd doesn't remember the power state, and the rfkill
>>> isn't
>>> tied to the Powered state. Calling to set the Power state will fail
>>> with the "Blocked" error, and we're expecting something else to
>>> unset
>>> the adapter's rfkill status.
>> 
>> My feeling is that you are running into the case where something
>> changed in the RFKILL subsystem or how systemd started to interact
>> with RFKILL. I have seen the cases where it boots up with a soft-
>> blocked state, but I never really tried to analyze the case.
> 
> That's a more likely problem, yes. Removing the Bluetooth files
> in /var/lib/systemd/rfkill/*:bluetooth seems to solve the problem.
> 
> I'll still need to find a way to avoid those inconsistent state
> problems.

I was never a fan of systemd trying to mess with RFKILL states. If you are not connection manager, you really have not enough information about how to deal with RFKILL switches.

What I think is the problem that systemd might better really only handle platform RFKILL switches and starts ignoring the ones that come from Bluetooth subsystem as part of the HCI controller.

>> The automatic power and remembering of powered state has been removed
>> since BlueZ 5.0, but recently we have introduced the AutoEnable
>> main.conf option in case you prefer to always power on your adapters
>> during early boot. This helps for cases where Bluetooth needs to be
>> up before an user logged in, but it also means that no agent is
>> available. So choose that option wisely.
> 
> I was wondering whether changes around this were responsible for the
> problem.
> 
>>> What did the developers making those changes hope that would
>>> unrfkill
>>> and power up the adapter when plugged in?
>>> 
>>> Note that this might be a side-effect of the machine I'm using
>>> which
>>> has 2 layers of Bluetooth rfkill:
>>> $ rfkill list bluetooth
>>> 0: tpacpi_bluetooth_sw: Bluetooth
>>> 	Soft blocked: no
>>> 	Hard blocked: no
>>> 4: hci0: Bluetooth
>>> 	Soft blocked: yes
>>> 	Hard blocked: no
>>> 
>>> hci0 won't be visible if tpacpi_bluetooth_sw is soft-killed. The
>>> work-
>>> around I have planned is to wait for "hci*" to appear if the
>>> Bluetooth
>>> rfkill we unset doesn't start with "chi".
>> 
>> That is the Thinkpad specific platform RFKILL switch that kills the
>> power to the USB device. Some platforms have this switches. They are
>> owned by the platform or ACPI. The hci0 is the one represented by the
>> Bluetooth subsystem.
> 
> Right, knew that, but was wondering whether the layering of rfkills, in
> addition to other changes, might have been the reason why this broke.

I do not recall any change in the subsystem that have caused this. So most likely this is systemd messing up things.

Regards

Marcel