BT advertising packets and s2idle issue

BT advertising packets and s2idle issue

[Christian Kellner]

Hi all,

I have been wondering what to do about the bug that advertising packet
will wake systems from s2idle when a device was previously paired with
the HCI_AUTO_CONN_ALWAYS flag (kernel bug #200039[1]). I was thinking of
creating a patch for bluez that would create a "delay lock"[2] and
de-register any such device from the kernel before entering s2idle, but
I wanted to check first if that is the best approach.
In comment #27 it is suggested that using a "LE Privacy v1.2" feature
could fix the issue as well. Is there some more information about this
available somewhere?  II can help out with development and testing as I
have an affected system myself.

Cheers,
CK

[1] https://bugzilla.kernel.org/show_bug.cgi?id=200039
[2] https://www.freedesktop.org/wiki/Software/systemd/inhibit/

--
Dr. Christian J. Kellner
Desktop Hardware Enablement
Red Hat

RE: BT advertising packets and s2idle issue

[Mario.Limonciello]

> -----Original Message-----
> From: Christian Kellner <ckellner@redhat.com>
> Sent: Monday, July 29, 2019 9:33 AM
> To: linux-bluetooth@vger.kernel.org
> Cc: Limonciello, Mario
> Subject: BT advertising packets and s2idle issue
> 
> 
> [EXTERNAL EMAIL]
> 
> 
> Hi all,
> 
> I have been wondering what to do about the bug that advertising packet
> will wake systems from s2idle when a device was previously paired with
> the HCI_AUTO_CONN_ALWAYS flag (kernel bug #200039[1]). I was thinking of
> creating a patch for bluez that would create a "delay lock"[2] and
> de-register any such device from the kernel before entering s2idle, but
> I wanted to check first if that is the best approach.
> In comment #27 it is suggested that using a "LE Privacy v1.2" feature
> could fix the issue as well. Is there some more information about this
> available somewhere?  II can help out with development and testing as I
> have an affected system myself.
> 
> Cheers,
> CK
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=200039
> [2] https://www.freedesktop.org/wiki/Software/systemd/inhibit/
> 
> --
> Dr. Christian J. Kellner
> Desktop Hardware Enablement
> Red Hat

If I'm not mistaken, even unpaired LE devices can cause the wakeup.  Any device
with an advertisement report will cause the wakeup.  So de-registering all devices
from kernel before entering s2idle wouldn't solve the problem.

My opinion is there should be a dedicated kernel freeze handler that does the following:
1) If LE Privacy 1.2 "in use", handle regular suspend/resume flow
2) If LE Privacy 1.1in use, power off the radio in freeze, power back on in resume.

For now, since LE privacy 1.2 not yet enabled, this would at least help with this
situation as reported.

Of course this will mean BT devices can't wake the system anymore if s2i, so maybe
the behavior  should be put behind a module parameter or sysfs file.

BLE devices are so prevalent though; I find it a hard time imagining anyone wants it
the way it exists today.

RE: BT advertising packets and s2idle issue

[Mario.Limonciello]

> -----Original Message-----
> From: Limonciello, Mario
> Sent: Wednesday, August 7, 2019 3:43 PM
> To: 'Christian Kellner'; linux-bluetooth@vger.kernel.org
> Subject: RE: BT advertising packets and s2idle issue
> 
> > -----Original Message-----
> > From: Christian Kellner <ckellner@redhat.com>
> > Sent: Monday, July 29, 2019 9:33 AM
> > To: linux-bluetooth@vger.kernel.org
> > Cc: Limonciello, Mario
> > Subject: BT advertising packets and s2idle issue
> >
> >
> > [EXTERNAL EMAIL]
> >
> >
> > Hi all,
> >
> > I have been wondering what to do about the bug that advertising packet
> > will wake systems from s2idle when a device was previously paired with
> > the HCI_AUTO_CONN_ALWAYS flag (kernel bug #200039[1]). I was thinking of
> > creating a patch for bluez that would create a "delay lock"[2] and
> > de-register any such device from the kernel before entering s2idle, but
> > I wanted to check first if that is the best approach.
> > In comment #27 it is suggested that using a "LE Privacy v1.2" feature
> > could fix the issue as well. Is there some more information about this
> > available somewhere?  II can help out with development and testing as I
> > have an affected system myself.
> >
> > Cheers,
> > CK
> >
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=200039
> > [2] https://www.freedesktop.org/wiki/Software/systemd/inhibit/
> >
> > --
> > Dr. Christian J. Kellner
> > Desktop Hardware Enablement
> > Red Hat
> 
> If I'm not mistaken, even unpaired LE devices can cause the wakeup.  Any device
> with an advertisement report will cause the wakeup.  So de-registering all devices
> from kernel before entering s2idle wouldn't solve the problem.
> 
> My opinion is there should be a dedicated kernel freeze handler that does the
> following:
> 1) If LE Privacy 1.2 "in use", handle regular suspend/resume flow
> 2) If LE Privacy 1.1in use, power off the radio in freeze, power back on in resume.
> 
> For now, since LE privacy 1.2 not yet enabled, this would at least help with this
> situation as reported.
> 
> Of course this will mean BT devices can't wake the system anymore if s2i, so
> maybe
> the behavior  should be put behind a module parameter or sysfs file.
> 
> BLE devices are so prevalent though; I find it a hard time imagining anyone wants
> it
> the way it exists today.

Another approach to this may be to submit a revert to the kernel for this commit:
https://github.com/torvalds/linux/commit/a0085f2510e8976614ad8f766b209448b385492f
until LE privacy support is in place.

This seems a regression to me that the system wakes up from any BLE traffic after that commit.

Re: BT advertising packets and s2idle issue

[Bastien Nocera]

On Mon, 2019-08-19 at 13:37 +0000, Mario.Limonciello@dell.com wrote:
> > 
<snip>
> Another approach to this may be to submit a revert to the kernel for
> this commit:
> https://github.com/torvalds/linux/commit/a0085f2510e8976614ad8f766b209448b385492f
> until LE privacy support is in place.
> 
> This seems a regression to me that the system wakes up from any BLE
> traffic after that commit.

You should send a revert and CC: the original author and committer on
it, otherwise I'm afraid that it might not get traction.

Cheers