Skip to contentSkip to conversation

BT advertising packet wakes up the system from S3 and suspend-to-idle

Bug 200039 [email protected] 2 participants 26 messages Oct 8, 2018 – May 14, 2022 1 message not in the archive Bluetooth drivers

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

author
#2 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #15 from Chethan T N ([email protected]) --- Hi,

Thank you for your email.
Am on vacatoin from WW41.1 to WW42.3. Please expect delay in mail response.

Please contact Arnaud([email protected]) for any technical information.

For any urgent information on please reach me on phone +919880015016.

Thanks and Regards
Chethan

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#4 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #17 from Raghuram Hegde ([email protected]) --- The presence of LE Advertisement reports in the btmon logs clearly suggests that there is either an Active scan or a Passive scan running. Since, the btmon logs attached are captured only during system suspend, we cannot conclude.

Please capture and attach the btmon logs for the complete flow (start btmon from the moment you initially pair the Logitech M585(BT4) mouse)

Thanks
Raghu

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#5 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #18 from AceLan Kao ([email protected]) --- Created attachment 279021
--> https://bugzilla.kernel.org/attachment.cgi?id=279021&action=edit
full log of btmon

Here is the full log of btmon

1. run "sudo btmon"
2. Open BT settings dialog
3. Connect and pair with Designer Mouse(BT4)
4. Disconnect the BT mouse
5. Close the BT settings dialog
6. Enter S3
7. System wakes up in couple seconds automatically
8. Stop "sudo btmon"

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#6 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #19 from Raghuram Hegde ([email protected]) ---

Thanks for the sharing complete btmon logs.
As evident from the below log snippet, once the remote device is disconnected, the host will start a Passive scan. The filter policy is set to "Accept all advertisement" as the previously paired device in the White List (Designer Mouse) has random address:

< HCI Command: Disconnect (0x01|0x0006) plen 3 #159 [hci0] 19.853664

        Handle: 3585
        Reason: Remote User Terminated Connection (0x13)
Quoted 1 line

HCI Event: Command Status (0x0f) plen 4 #160 [hci0] 19.855749

      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
Quoted 1 line

HCI Event: Disconnect Complete (0x05) plen 4 #161 [hci0] 19.903759

        Status: Success (0x00)
        Handle: 3585
        Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Command Complete (0x0001) plen 10       {0x0001} [hci0] 19.903829
      Disconnect (0x0014) plen 7
        Status: Success (0x00)
        LE Address: DF:29:ED:8F:82:95 (Static)
@ MGMT Event: Device Disconnected (0x000c) plen 8     {0x0003} [hci0] 19.903852
        LE Address: DF:29:ED:8F:82:95 (Static)
        Reason: Connection terminated by local host (0x02)
@ MGMT Event: Device Disconnected (0x000c) plen 8     {0x0002} [hci0] 19.903852
        LE Address: DF:29:ED:8F:82:95 (Static)
        Reason: Connection terminated by local host (0x02)
< HCI Command: LE Set Scan Parame.. (0x08|0x000b) plen 7  #162 [hci0] 19.949197
        Type: Passive (0x00)
        Interval: 60.000 msec (0x0060)
        Window: 30.000 msec (0x0030)
        Own address type: Public (0x00)
        Filter policy: Accept all advertisement (0x00)
Quoted 1 line

HCI Event: Command Complete (0x0e) plen 4 #163 [hci0] 19.949798

      LE Set Scan Parameters (0x08|0x000b) ncmd 1
        Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2    #164 [hci0] 19.949848
        Scanning: Enabled (0x01)
        Filter duplicates: Enabled (0x01)
Quoted 1 line

HCI Event: Command Complete (0x0e) plen 4 #165 [hci0] 19.951759

      LE Set Scan Enable (0x08|0x000c) ncmd 2
        Status: Success (0x00)

Since, passive scan is going on when the system is put to suspend, the system wakes up when any Advertisement report is received.

Thanks,
Raghu

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#7 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #20 from Raghuram Hegde ([email protected]) --- (In reply to AceLan Kao from comment #18)

Quoted 5 lines

Created attachment 279021 [details]
full log of btmon

Here is the full log of btmon

Quoted 8 lines

1. run "sudo btmon"
2. Open BT settings dialog
3. Connect and pair with Designer Mouse(BT4)
4. Disconnect the BT mouse
5. Close the BT settings dialog
6. Enter S3
7. System wakes up in couple seconds automatically
8. Stop "sudo btmon"

As explained in my previous comment, this is a normal/expected behavior as the passive scan is running in background.

Request you to close this bug.

Thanks,
Raghu

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#8 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #21 from Mario Limonciello ([email protected]) ---

Quoted 2 lines

As explained in my previous comment, this is a normal/expected behavior as the passive scan is running in background.

Shouldn't the kernel driver cancel any currently active passive scans during it's suspend call back methods?

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#9 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #22 from AceLan Kao ([email protected]) ---
I think the behavior should be normal.
When BT dialog is opened, it start accepting all advertisement, and stop receiving packet after it's closed. This behavior is easy to be observed. From the full log, packets before #219 are received when the BT dialog is opened, and #220 is received during S3.

But the issue is, the advertising packets are only be received after there is a paired BT4 device(no matter it's connected or not).
It very simple to verify.

1. remove all BT devices from BT dialog and close the BT dialog
2. run "btmon" and got nothing

1. pair non-BT4 devices(you can leave it connected) and close BT dialog
2. nothing from "btmon" if you don't touch the paired device.

1. pair BT4 devices and disconnected them(even power off them)
2. we got advertising packet from other BT4 devices.

I'm not sure if "Accept all advertisement" is the culprit, but I'm willing to know if there is any command we can try to disable it to see if it helps.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#10 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #23 from Raghuram Hegde ([email protected]) --- (In reply to AceLan Kao from comment #22)

Quoted 13 lines

I think the behavior should be normal.
When BT dialog is opened, it start accepting all advertisement, and stop receiving packet after it's closed. This behavior is easy to be observed. From the full log, packets before #219 are received when the BT dialog is opened, and #220 is received during S3.

But the issue is, the advertising packets are only be received after there is a paired BT4 device(no matter it's connected or not).
It very simple to verify.

1. remove all BT devices from BT dialog and close the BT dialog
2. run "btmon" and got nothing

Quoted 8 lines

1. pair non-BT4 devices(you can leave it connected) and close BT dialog
2. nothing from "btmon" if you don't touch the paired device.

1. pair BT4 devices and disconnected them(even power off them)
2. we got advertising packet from other BT4 devices.

I'm not sure if "Accept all advertisement" is the culprit, but I'm willing to know if there is any command we can try to disable it to see if it helps.

In the full log, you can see that after #123, MGMT command 'Add Device' is sent with Action parameter set to 'Auto-connect remote device (0x02)'. So, when pairing with a LE device, 'HCI_AUTO_CONN_ALWAYS' flag is set.

In the HCI Disconnection Complete Event handler (hci_disconn_complete_evt in net/bluetooth/hci_event.c), you can see that if the 'HCI_AUTO_CONN_ALWAYS' flag is set, LE passive scan will be started.

Since for a paired LE device, 'HCI_AUTO_CONN_ALWAYS' flag is set, when we disconnect it, LE passive scan will be started.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#11 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #24 from AceLan Kao ([email protected]) ---
Setup 'HCI_AUTO_CONN_ALWAYS' flag and "Accept all advertisement" do not mean the advertising packet should wake up the system. We even powered off the paired device, but the system still be waken up by advertising packets from other random BT4 devices.

I got some questions for you and would like to figure out a feasible solution for the issue.
1. Do you have any idea about who decide to wake up the system when the advertising packet is received? Firmware or driver?
2. Do you know how windows handle this? Does the advertising packet wake up windows?
3. Is there any drawback if we remove 'HCI_AUTO_CONN_ALWAYS' flag when suspending?
Thanks.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#12 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #25 from Raghuram Hegde ([email protected]) --- (In reply to AceLan Kao from comment #24)

Quoted 5 lines

Setup 'HCI_AUTO_CONN_ALWAYS' flag and "Accept all advertisement" do not mean the advertising packet should wake up the system. We even powered off the paired device, but the system still be waken up by advertising packets from other random BT4 devices.

Quoted 9 lines

I got some questions for you and would like to figure out a feasible solution for the issue.
1. Do you have any idea about who decide to wake up the system when the advertising packet is received? Firmware or driver?
2. Do you know how windows handle this? Does the advertising packet wake up windows?
3. Is there any drawback if we remove 'HCI_AUTO_CONN_ALWAYS' flag when suspending?
Thanks.

Quoting the below paragraph under section Suspend-to-Idle from Kernel documentation (Documentation/admin-guide/pm/sleep-states.rst)
"The system is woken up from this state by in-band interrupts, so theoretically any devices that can cause interrupts to be generated in the working state can also be set up as wakeup devices for S2Idle."

The wakeup interrupts for the system in sleep state can be either enabled or disabled in /proc/acpi/wakeup file.
I suppose, the USB hub to which the BT controller is attached has the 'Status' column set to 'enabled' for S-state S3.

Now, when an Advertisement packet is received by the BT controller during active/passive scan, the Advertisement Report Event is sent to the Host via HCI interface (USB transport layer). This HCI event is sent as a packet on the USB bus. Now, the USB bus wakes up the system (remote-wakeup) from suspend.

You can give the following a try and check if the advertisement reports are waking up the system from suspend:
Disable the interrupt source(device) in /proc/acpi/wakeup
Eg: If BT controller is attached to EHC2;
echo EHC2 > /proc/acpi/wakeup [This will toggle the 'Status' column from enabled <-> disabled]

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#13 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #26 from AceLan Kao ([email protected]) --- Disable the S3 wakeup in /proc/acpi/wakeup doesn't work. Disable the wakeup from the usb devices directly doesn't work, either.
echo disabled | sudo tee
/sys/devices/pci0000:00/0000:00:14.0/usb*/power/wakeup
We also try to block the the rfkill devices by
echo 1 | sudo tee /sys/class/rfkill/rfkill*/soft
but it still doesn't work.

The only workaround we can find is to stop the bluetooth daemon before entering S3
sudo systemctl stop bluetooth

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#14 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #27 from Raghuram Hegde ([email protected]) --- In Bluetooth 4.1(LE Privacy 1.1), the Private address Resolving List is maintained in the Host. Address resolution is also done by the Host. This requires Host intervention every time an advertisement packet with an RPA is received.

In Bluetooth 4.2(LE Privacy 1.2),
the Resolving List is maintained in the Controller. Since the Controller resolves the private address, the Host does not need to wake up in devices where the Host is implemented using a separate CPU. This lowers overall power consumption.

Having said that, Intel controller does support LE Privacy v1.2 feature. However Linux kernel need to enable to make use of the Link Layer privacy to avoid this kind of issues.

This is generic problem/behavior observed on other vendors BT controller as well that does not support LE privacy 1.2 feature.

We highly recommend to enable LE privacy 1.2 to solve the problem.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#16 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

[email protected] changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #29 from [email protected] ---
This is still an issue for me with 4.20 and an Intel AC-9260 card. If Bluetooth is on, my computer will refuse to sleep or begin to sleep before aborting. It will freeze if kept in this cycle for long enough.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#17 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #30 from Kai-Heng Feng ([email protected]) --- (In reply to Raghuram Hegde from comment #27)

Quoted 1 line

We highly recommend to enable LE privacy 1.2 to solve the problem.

How to get this feature enabled?

After I ran:
btmgmt power off
btmgmt privacy on
btmgmt power on

The issue still occurs.

I can see that in mgmt.c's set_privacy(), HCI_PRIVACY is set and HCI_LIMITED_PRIVACY gets cleared, do they roughly translate to LE Privacy 1.2 and LE Privacy 1.1, respectively?

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#20 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

Tom Hale ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #34 from Tom Hale ([email protected]) ---
--- WORKAROUND ---

I've posted a systemd unit file and script on Unix and Linux Stack Exchange which automatically disables and re-enables the USB bluetooth device on sleep / suspend.

https://unix.stackexchange.com/questions/539762/how-do-i-suspend-sleep-while-bluetooth-is-active/539763#539763

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#21 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #35 from Mario Limonciello ([email protected]) --- @Tom:

The offending commit that caused this behavior is being reverted for 5.4:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=1ffdb51f28e8ec6be0a2b812c1765b5cf5c44a8f

You may also need to update to latest linux-firmware.git as well if your distro has old firmware.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#22 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #36 from Luiz Von Dentz ([email protected]) --- (In reply to Mario Limonciello from comment #35)

Quoted 8 lines

@Tom:

The offending commit that caused this behavior is being reverted for 5.4:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/
commit/?id=1ffdb51f28e8ec6be0a2b812c1765b5cf5c44a8f

You may also need to update to latest linux-firmware.git as well if your distro has old firmware.

Is is actually disabling remote wakeup? Doesn't that disable RX to wakeup the host which pretty much breaks any traffic initiate from either the controller or the remote device? If that is the case we might as well remove support for auto-suspend since this would never gonna work if the controller cannot wakeup the host.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#23 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #38 from Luiz Von Dentz ([email protected]) ---
I wonder if we could actually make the remote wakeup conditional to auto-suspend since that is what we want so in case the host suspend the device can still wakeup if auto-suspend has been enabled, so platforms which has a problem with that shall never mark BT controller to auto-suspend.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
author
#24 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #39 from Mario Limonciello ([email protected]) --- So the idea would be you don't auto-suspend the btusb device and then as a result the btusb device can't wake up? I think the potential problem there is that the BT controller would stay powered over s2idle which should keep the USB active, and potentially prevent the SOC from reaching it's deepest state.

Signature · 2 lines
You are receiving this mail because:
You are the assignee for the bug.
#25 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

Bernie Innocenti ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #40 from Bernie Innocenti ([email protected]) ---
Not sure if I'm seeing the same bug, but my Lenovo X1 Gen7 wakes up immediately after entering S3 when a BT headphone is paired.

The Bluetooth adapter is the same: Intel 8087:0aaa Kernel version: 5.17.7-300.fc36.x86_64

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.
#26 lore raw
In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #41 from Bernie Innocenti ([email protected]) --- (In reply to Bernie Innocenti from comment #40)

Quoted 2 lines

Not sure if I'm seeing the same bug, but my Lenovo X1 Gen7 wakes up immediately after entering S3 when a BT headphone is paired.

I found the same bug documented here:
https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(Gen_7)#S3_Suspend_Bug_with_Bluetooth_Devices

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.