Hi, Since commit d5bb334a8e171b262e48f378bd2096c0ea458265 some devices doesn't connect via bluetooth (like Sixaxis gamepad). 'bluetoothctl' shows that device is connected, and soon after disconnected. Link for commit which causes the issue: https://github.com/torvalds/linux/commit/d5bb334a8e171b262e48f378bd2096c0ea458265 I checked the "conn->enc_key_size", it reports the value of 0 for Sixaxis gamepad (not the value of 7, which is the minimum encryption key size). I noticed that other people also having issue after kernel upgrade, but I'm not sure if it exactly the same bug: https://forum.manjaro.org/t/solved-bluetooth-fail-after-2019-05-17-stable-update/87892
I can confirm this bug for DualShock 3 as well.
Some more possibly-related links: - https://dev.getsol.us/T7970 - https://www.spinics.net/lists/linux-bluetooth/msg80104.html - https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/674
Commenting out the if-statement in d5bb334a allows my DualShock 3 controller connect on Linux 4.19.44.
I confirm the bug related to this commit, and to its backported version in 5.0.15. My device is a Sony DR-BT21G headset. With this commit, the hcidump reports this error message: > ACL data: handle 256 flags 0x02 dlen 12 L2CAP(s): Connect req: psm 3 scid 0x0041 < ACL data: handle 256 flags 0x00 dlen 16 L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0041 result 3 status 0 Connection refused - security block Without it, the hcidump reports a successful connection: > ACL data: handle 256 flags 0x02 dlen 12 L2CAP(s): Connect req: psm 3 scid 0x0041 < ACL data: handle 256 flags 0x00 dlen 16 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0041 result 0 status 0 Connection successful
Created attachment 282895 [details] hcidump of a failed connection
Created attachment 282897 [details] hcidump of a succesful connection
I cannot connect Logitech BT mouse using kernel 5.0.15 or higher. Works fine with 5.0.14 or lower. See: https://bugzilla.redhat.com/show_bug.cgi?id=1711468
Anyone's planning to send a patch that reverts subj commit?
This RFC patch works for me: https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@holtmann.org/T/#u
Sadly the RFC patch above does not fix it for me, the revert does The device is edifier w330nb headset. hcidump fragment of failed connection: > 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
Just chiming in to report that this bug also affects HHKB-BT Pro (Happy Hacking BT Keyboard). It happens regardless of which BT controllor/adaptor that I use. I haven't yet had the chance to attempt backing out the change conditional that could be causing the issue in 5.0.16, but will try to find time in the next week or so. With the breadth of devices that are affected, I imagine this should be fixed quickly.
For my Logitech BT 2.0 mouse, this bug is fixed by Fedora kernel 5.1.4. Thanks for your efforts.
(In reply to didierg from comment #12) > For my Logitech BT 2.0 mouse, this bug is fixed by Fedora kernel 5.1.4. For reference to others Fedora pulled in the RFC patch to the Fedora 5.1.4 build.
I can confirm that the patch fixes the issue for me on Linux 4.19.46.
Just came here to say that "Kensington SlimBlade Trackball Mouse" are also affected by this regression. Bisected this before I found this bug report via the commit id :-)
One more that the RFC patch fixes: "Goldtouch Bluetooth Keyboard" on kernel 5.1.6.
I have several brandless (Made in china) mice affected by this regression. Up to 5.1.7 at least, the fix wasn't merged (just saying for whomever comes with that doubt in mind).
Same issue with my Wii U Pro controller, and the RFC patch fixes it as well. Thanks!
*** Bug 203661 has been marked as a duplicate of this bug. ***
(In reply to Andriy Perevortkin from comment #10) > Sadly the RFC patch above does not fix it for me, the revert does > The device is edifier w330nb headset. It also did not fix it for my two Sony DualShock 4 Wave Blue CUH-ZCT1 (the issue was reproducible with both), although it did for the following devices: * Sony DualShock 4 Glacier White CUH-ZCT1 (same generation as the Wave Blue ones); * Microsoft Bluetooth Mobile Keyboard 6000; * Memteq Bluetooth Optical Mouse. The only way to solve the issue for my two DualShock 4 Wave Blue was to revert the culprit commit, just like it has been done recently -> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.1.10&id=b528880e8b0167c34cb36c1b4e6165192f76267c Just to confirm that patch does not work for all devices.
This also affects the PS3 Blu-Ray Remote control, which I use for my media server. After many hours of debugging I came across this regression. Any news on when the fix (revert commit d5bb334a8e171b262e48f378bd2096c0ea458265) will reach upstream?
Hi Martin, There is another regression: https://bugzilla.kernel.org/show_bug.cgi?id=203997 If the remote control has minimum enc key size of 7, then this is most likely same problem. Could you check with btmon? Feel free to try the patch posted on mailing list. Br, Matias