FS#62776 - [linux]DualShock 4 and other devices not connecting with bluetooth since 5.1.

Attached to Project: Arch Linux
Opened by Marc Geerlings (markus-66) - Wednesday, 29 May 2019, 09:18 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 02 March 2021, 06:33 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Andreas Radke (AndyRTR)
Jan Alexander Steffens (heftig)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 14
Private No

Details

Description: DualShock 4 not connecting with bluetooth since 5.1.

Problem is not only related to the Dualshock 4, on forums there is more talk about bluetooth devices unable to connect. Fedora already applied an patch in the kernel 5.1.4 release (see link below)

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

Additional info:
* package version(s) linux 5.1 to 5.1.5, not tried but on forums the latest LTS version has the same issue.

* config and/or log files etc.
> HCI Event: Link Key Request (0x17) plen 6

bdaddr 5C:C6:E9:11:B1:20
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
bdaddr 5C:C6:E9:11:B1:20 key 9290EB1424E3A352C43F17C8499A3670
> HCI Event: Command Complete (0x0e) plen 10

Link Key Request Reply (0x01|0x000b) ncmd 1
status 0x00 bdaddr 5C:C6:E9:11:B1:20
> HCI Event: Encrypt Change (0x08) plen 4

status 0x00 handle 256 encrypt 0x01
< HCI Command: Read Encryption Key Size (0x05|0x0008) plen 2
> ACL data: handle 256 flags 0x02 dlen 12

L2CAP(s): Connect req: psm 25 scid 0x0580
< ACL data: handle 256 flags 0x00 dlen 16
L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0580 result 3 status 0
Connection refused - security block
> HCI Event: Command Complete (0x0e) plen 7

Read Encryption Key Size (0x05|0x0008) ncmd 1
> HCI Event: Number of Completed Packets (0x13) plen 5

handle 256 packets 1
> HCI Event: Disconn Complete (0x05) plen 4

status 0x00 handle 256 reason 0x13
Reason: Remote User Terminated Connection

* link to upstream bug report, if any

Steps to reproduce:
Pair DS4 with bluez. DS4 connects.
Switch off DS4.
Turn on DS4, DS4 connects and immediatly turns off.
Repeat with same result...
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Tuesday, 02 March 2021, 06:33 GMT
Reason for closing:  Fixed
Comment by Marc Geerlings (markus-66) - Wednesday, 29 May 2019, 09:23 GMT
I want to add, reverting to 5.0.10 (last kernel I had in /var/cache/pacman/pkg) solves the connection problems.
Comment by Gero (jlp2) - Thursday, 30 May 2019, 18:54 GMT
I confirm the bug with an Apple Magic Mouse and its backported to version 5.0.15.

For reference to others Fedora pulled in an RFC patch to the Fedora 5.1.4 build and the bug seemed to be fixed...

„https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@holtmann.org/“

Fixes: d5bb334a8e17 ("Bluetooth: Align minimum encryption key size for LE and BR/EDR connections")
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
---
net/bluetooth/hci_conn.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 3cf0764d5793..7516cdde3373 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -1272,8 +1272,13 @@ int hci_conn_check_link_mode(struct hci_conn *conn)
return 0;
}

- if (hci_conn_ssp_enabled(conn) &&
- !test_bit(HCI_CONN_ENCRYPT, &conn->flags))
+ /* If Secure Simple Pairing is not enabled, then legacy connection
+ * setup is used and no encryption or key sizes can be enforced.
+ */
+ if (!hci_conn_ssp_enabled(conn))
+ return 1;
+
+ if (!test_bit(HCI_CONN_ENCRYPT, &conn->flags))
return 0;

/* The minimum encryption key size needs to be enforced by the
--
2.20.1

Comment by Gero (jlp2) - Thursday, 30 May 2019, 19:09 GMT Comment by Gero (jlp2) - Monday, 03 June 2019, 08:35 GMT
Sadly with linux 5.1.6 the Bug is still persistend....
Comment by Martin Corley (martinc) - Wednesday, 05 June 2019, 15:10 GMT
Just to confirm that the RFC patch works for me (on 5.1.6, 5.1.7)
Comment by Marc Geerlings (markus-66) - Wednesday, 12 June 2019, 08:58 GMT
All 5.1.x versions up to 5.1.8 have the same problem, reverting to 5.0.10 solves it.
Comment by loqs (loqs) - Saturday, 15 June 2019, 11:37 GMT Comment by Marc Geerlings (markus-66) - Tuesday, 18 June 2019, 12:28 GMT
I can confirm, I upgraded to kernel 5.1.11 and bluetooth is functioning normal again.
Comment by Christopher Snowhill (kode54) - Wednesday, 24 July 2019, 06:32 GMT
I can confirm, I am running kernel 5.2.2 and bluetooth is still broken.
Comment by Dennis W (archNewbieX) - Monday, 29 July 2019, 21:41 GMT
Probably the same bug as mine.
https://bugs.archlinux.org/task/63198
Comment by Michał (lisu_ml) - Saturday, 07 March 2020, 14:05 GMT
  • Field changed: Percent Complete (100% → 0%)
I'm having the issue originally reported in this issue with kernel 5.5.8-arch1-1, so either the issue re-appeared in newer versions of kernel or it was not fully fixed.
Comment by loqs (loqs) - Saturday, 07 March 2020, 14:53 GMT
@lisu_ml what kernel version introduced the issue? Have you bisected between that version and the last good version to find the causal commit?
Please attach the dmesg from boot with and without the issue. What device are you producing the issue with?
What is the output from hcidump with and without the issue?
Comment by Michał (lisu_ml) - Monday, 09 March 2020, 09:17 GMT
I was about to dive deeper into my investigations as I had no idea which kernel version introduced the issue, as I got my lenovo bluetooth compact keyboard only recently. I found out that hcidump command is missing in my OS, so I stared to look for the package that provides it. It turned out the binary is provided by bluez-utils-compat AUR package which conflicts with bluez-utils one from extra. When I replaced the latter with the former not only I got bunch of additional tools, but also my issue is no more and my keyboard is able to automatically re-connect. What I'm not sure about is why the package officially supported by Arch Linux doesn't provide full support for some bluetooth devices, but I'm ok with using AUR package instead.
Comment by Jan Alexander Steffens (heftig) - Saturday, 25 April 2020, 14:09 GMT
@andyrtr Is there something important missing from our bluez-utils?
Comment by AK (Andreaskem) - Saturday, 25 April 2020, 14:38 GMT
I think hcidump is deprecated and btmon is supposed to be its replacement.
Comment by Andreas Radke (AndyRTR) - Saturday, 25 April 2020, 17:14 GMT
We only disable deprecated tools. All configuration and debugging should be possible without the old files.

I guess is a different issue behaving similar. I've seen reports about broken devices with last bluez release that can be fixed using bluez-git from AUR.
Comment by Andreas Radke (AndyRTR) - Tuesday, 26 May 2020, 19:40 GMT
I can't find any other difference between the official and the AUR package that just brings back the deprecated tools. None if them should be required to get your device work.
If so it's a bug and should be reported upstream to get it fixed for the future.
Comment by Andreas Radke (AndyRTR) - Monday, 16 November 2020, 10:56 GMT
Still waiting for somebody affected to report this upstream so they get aware of this.
Comment by Antoni (antuaw) - Sunday, 22 November 2020, 17:53 GMT
I'm currently experiencing issue with connecting either Dualshock 3 or Dualshock 4 controllers (yesterday it worked, but also yesterday my PC experienced a power outage so I'm not sure if that could be a cause :( ). Tried to solve it for an entire day today but without success. That is why I registered here as that is the most close description of what I'm experiencing. Tried already downgrading to 5.54-2 from 5.55 and tried the bluez from aur - both solutions were not successful.

I'm eager to share any required logs but would need someone to tell me what is needed.

First thing I noticed that is different in journalctl before and after the issue occurred is new logs, for example:
1) Nov 22 10:00:39 PC kernel: Bluetooth: hci0: ACL packet for unknown connection handle 12
and
2) Nov 22 11:54:53 PC kernel: Bluetooth: hci0: ACL packet for unknown connection handle 2050

I also can't connect any other bluetooth device. (although bluetoothctl says controllers are connected for few seconds the corresponding /dev/input/* devices are not appearing)
The controller still work when plugged by cable.

Linux PC 5.9.9-arch1-1 #1 SMP PREEMPT Wed, 18 Nov 2020 19:52:04 +0000 x86_64 GNU/Linux
blueman 2.1.3-1
bluez 5.55-1
bluez-libs 5.55-1
bluez-plugins 5.55-1
bluez-utils 5.55-1
pulseaudio-bluetooth 13.99.3+4+gd83ad6990-1
Comment by mattia (nTia89) - Tuesday, 08 December 2020, 20:24 GMT
Possibly related with  FS#68479 
Comment by Andreas Radke (AndyRTR) - Monday, 08 February 2021, 10:37 GMT
Is there any bug report or communication done by affected users to the upstream project project and their tracker to follow?
Comment by Naleo (naleo) - Tuesday, 02 March 2021, 03:06 GMT
I think I am running into this error, and I am happy try and report it upstream, but not quite sure where. Could I get some direction where I should report this?
Comment by Andreas Radke (AndyRTR) - Tuesday, 02 March 2021, 06:32 GMT
The initial bug seems solved. Everything else should be reported into different bug reports to sort and fix them one by one.

Loading...