BT advertising packets and s2idle issue
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
Quoted 27 lines
-----Original Message-----
From: Christian Kellner <[email protected]>
Sent: Monday, July 29, 2019 9:33 AM
To: [email protected]
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_ALWAYSflag (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
Quoted 7 lines
[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.
Quoted 53 lines
-----Original Message-----
From: Limonciello, Mario
Sent: Wednesday, August 7, 2019 3:43 PM
To: 'Christian Kellner'; [email protected]
Subject: RE: BT advertising packets and s2idle issueQuoted 27 lines
-----Original Message-----
From: Christian Kellner <[email protected]>
Sent: Monday, July 29, 2019 9:33 AM
To: [email protected]
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_ALWAYSflag (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,
CKQuoted 7 lines
[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 HatIf 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.
Quoted 7 lines
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.
Quoted 1 line · On Mon, 2019-08-19 at 13:37 +0000, [email protected] wrote:
Quoted 1 line
<snip>
Quoted 7 lines
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