After updating to version 5.64-0ubuntu1.1 my gamepad stopped working.

[Ancapzin]

The earbuds are fine but my gamepad stopped working.

[rs-gh-asdf]

Hello, I am also experiencing this issue. I reported it on Canonical's launchpad bug reporter here, but given past experience on launchpad, I am doubtful that it will get a reply. Here is the important section of my bug report that might be helpful for the developers:

Logs (journalctl) that I get on connection with the broken (new) version:

Dec 10 13:12:23 laptop bluetoothd[6317]: src/profile.c:record_cb() Unable to get Hands-Free Voice gateway SDP record: Host is down
Dec 10 13:12:43 laptop bluetoothd[6317]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info
Dec 10 13:12:45 laptop bluetoothd[6317]: profiles/input/device.c:hidp_add_connection() Rejected connection from !bonded device E4:17:DE:AD:BE:EF

Logs (journalctl) that I get on connection with the old (working) version:

Dec 10 13:37:17 laptop bluetoothd[7736]: src/profile.c:record_cb() Unable to get Hands-Free Voice gateway SDP record: Host is down
Dec 10 13:38:30 laptop bluetoothd[7736]: profiles/input/device.c:ioctl_is_connected() Can't get HIDP connection info

I compiled HEAD on the master branch (with a custom prefix), did a sudo systemctl stop bluetooth; systemctl stop --user obex, and then manually ran the daemons with sudo my_prefix/libexec/bluetooth/bluetoothd & my_prefix/libexec/bluetooth/obexd and I was able to observe the problem behavior:

• No /dev/input/js0
• Controller not detected by any software that I have tried, including ares and jstest-gtk

Although no error messages are printed to stdout or stderr, I do see a similar error message in /var/log/syslog:

2023-12-10T15:19:45.337892-08:00 laptop bluetoothd[25026]: profiles/input/device.c:hidp_add_connection() Rejected connection from !bonded device /org/bluez/hci0/dev_E4_17_DE_AD_BE_EF

I also double-checked that the PID referenced in this syslog message is the PID of the git HEAD version of bluetoothd that I am manually running. I don't know much about kernel bluetooth internals, but I tried clicking "Trust" on the device in blueman-applet and then pairing with it, but I still got the same error message and behavior.

[rs-gh-asdf]

After looking at the existing issues reported on this github, I thought that we might be dealing with a duplicate of #605, so I tried to replicate the issue using bluetoothctl instead of blueman-applet. To my surprise, pairing with bluetoothctl resolved the issue. I was even able to disconnect and reconnect the gamepad automatically after using the bluetoothctl trust command and it still worked, which had not been the case before when using blueman-applet's GUI functionality. It looks like this isn't an issue in bluez, but rather in blueman. For others who find this in the future:

1. Disconnect your gamepad with blueman and remove the device
2. bluetoothctl
3. scan on and wait a second
4. devices and copy the MAC of the device that you want to pair
5. pair MAC_ADDRESS
6. connect MAC_ADDRESS
7. trust MAC_ADDRESS

[GuillaumeCisco]

I have the same issue.
I succeeded connecting the Switch Pro Controller gamepad but first removing it from blueman.
Then from bluetoothctl:

• trust <MAC_ADDRESS>
• pair <MAC_ADDRESS>
• connect <MAC_ADDRESS>

This was the only way for connecting it correctly for after being displayed in evdev python package.

[rs-gh-asdf]

I thought that this was an issue with blueman so I opened an issue on their github here but after some troubleshooting, the blueman maintainers think that this is actually a bug with bluez. Specifically "the device does not get marked as bonded at any time if it's not explicitly paired". This behavior is consistent across both bluetoothctl and blueman.

To create the problem behavior:

• Disconnect from the device
• "Connect" to the device without first "Pairing" with it
  • In blueman this is done by clicking the "Connect" button
  • In bluetoothctl this is done with connect MAC_ADDR
• The device is not marked as "Bonded" and does not show up at /dev/input/js0

To create the working behavior

• Disconnect from the device
• "Pair" with the device and then "Connect" to it
  • In blueman this is done by first clicking the "Pair" button and then clicking the "Connect" button
  • In bluetoothctl this is done by first running pair MAC_ADDR and then running connect MAC_ADDR
• The device is marked as "Bonded" and works as expected

The device must first be paired before it is connected, otherwise it will not work. This is different than the user-observable behavior that was present before the update, where unpaired-but-connected devices worked fine.

[jerekulmala]

On Archlinux after updating to 5.70-2 my ps3 controller stopped connecting and started asking for a pin code to connect. The update adds a patch for CVE-2023-45866. Downgrading seems to fix the issue. Seems like Ubuntu started shipping the same patch in 5.68-0ubuntu1.1, 5.66-0ubuntu1.1, 5.64-0ubuntu1.1 etc.

[rs-gh-asdf]

@jerekulmala do you still have the same issue with the updated version if you first pair and then connect?

[jerekulmala]

@rs-gh-asdf When I pair the controller I plug it in with usb and press the ps button, take the usb cable out and then press again then it should connect, so I think I can't try the pair command with a ps3 controller. In bluetoothctl when trying to connect it gives me [agent] Enter PIN code: and trying any pin code, like 0000, it looks like the controller connects but looking at the ps3 controller 4 lights are blinking when normally connected one light stays on.

After adding a config file in /etc/bluetooth/input.conf with ClassicBondedOnly=false I can connect the ps3 controller even with the newer version.

[cschramm]

Both the Ubuntu and the Arch Linux patches are simply 25a471a, i.e. they enable the ClassicBondedOnly option by default.

[sltvtr]

I have the exact same issue with Wii Remote after bluez updated to *ubutnu1.1.
Thanks to this thread I found out workaround which is simply downgrading.
And for me pairing is not an option because WiiMotes don't support pairing (no PIN for pairing).

quote from xwiimote manual:

If you are  asked  for  PIN  input  while  bonding  the
       devices,  then  your BlueZ bluetoothd daemon does not include the wiimote plugin. See Bugs
       below for more information. If this does not help, you  can  still  connect  to  your  Wii
       Remote  without  pairing/bonding  (i.e. not using authentication with a PIN).  This should
       work with any BlueZ version.

[quickishfm]

I have the same issue on Arch Linux. @rs-gh-asdf I tried your method but can't seem to replicate your success in pairing before connection. My PS3 controller remembers my computers bt MAC address to try and connect to when I turn on the controller with the PS button. I can't pair first, because the second I turn my controller on it tries to connect back to my PC with "PIN required to pair", which is the problem. I can't seem to pair with it in bluetoothctl either.

[bluetooth]# hci0 00:24:33:XX:XX:XX type BR/EDR connect failed (status 0x04, Connect Failed)
[bluetooth]# Failed to pair: org.bluez.Error.ConnectionAttemptFailed

This is while it's plugged in by USB cable - which is the only way I can have the bluetooth of the controller ON but not actively trying to connect to my PC. So I don't know how you're able to "pair" before connecting it. Is there something I'm missing?

(I did NOT set the ClassicBondedOnly yet, I wanted to try this first)

[rs-gh-asdf]

Hi @quickishfm, I am not using a PS3 controller. I am using an 8bitdo Pro 2. I did not know about the PS3 controller's weird connecting system before I began looking into this issue. I think that you are having the same issue as @jerekulmala and I suspect that their solution would work for you too.

Sorry I can't be more help. I'm not a developer or contributor on this project - I just want to play video games.

[quickishfm]

Thanks @rs-gh-asdf I see.
@jerekulmala I have latest bluez packages from Arch repo (5.71-1) and I created /etc/bluetooth/input.conf with only line in there being ClassicBondedOnly=false. I still get the problem that it asks for PIN code when I turn on the controller.

EDIT:
I resolved the issue by adding [General] to the conf file. Now etc/bluetooth/input.conf reads as

[General]
ClassicBondedOnly=false

It worked after I trusted the MAC address using bluetoothctl.

It's annoying that I have to regress on security to get this controller working again :/

EDIT 2:
The only way I can see to "keep" it working with the security improvement in place is to just use it over USB. While it keeps asking to pair when disconnected from USB, you can avoid this by writing a different MAC address to the controller (as the "host" device it needs to connect to) so it doesn't keep trying to connect back to the PC. That, or just disable Bluetooth. It's not really a fix because it defeats the purpose of having a wireless controller to begin with though.

[corigne]

Is it possible to fix this without requiring a user to roll back security features?

[alexdelorenzo]

I am experiencing the same issue, and I've yet to find a controller that doesn't have this issue.

With two different computers and 4 different Bluetooth adapters, I have tried:

• 8bitdo's Ultimate C Bluetooth controller
• VOYEE's Switch controller
• Original PS3 controller
• Copycat PS3 controller
• Original Wii remote

The first four of these work over USB, and they all work over Bluetooth on older Bluez versions and on the latest version with ClassicBondedOnly=false set.

They'll connect over Bluetooth but aren't registered as evdev input devices, so no /dev/input/js* devices get created.

[xadips]

@rs-gh-asdf Could reproduce on 2 separate 8Bit do Pro 2 controllers 5.71 Arch

[riquezjp]

I resolved the issue by adding [General] to the conf file.

I have to say OMGPONIES11 ive been struggling with this for about 2 years. I am now free of the cable & my gaming can begin. Thanks .

[DrKlipper]

Running a Pi4 with a bullseye image and bluez 5.55.
I tried ClassicBondedOnly=false but my mini gamepad (http://www.migamepad.com/sweb/android/english/cur_op_select.jsp?cur_type=032) won´t connect:

@ MGMT Event: Device Connected (0x000b) plen 40                                                                            {0x0001} [hci0] 6.596612
        BR/EDR Address: 17:05:16:03:35:E1 (OUI 17-05-16)
        Flags: 0x00000008
          Unknown device flag (0x00000008)
        Data length: 27
        Name (complete): MOCUTE-032S_A03-35E1
        Class: 0x000540
          Major class: Peripheral (mouse, joystick, keyboards)
          Minor class: 0x10
< HCI Command: Authentication Requested (0x01|0x0011) plen 2                                                                    #21 [hci0] 6.596663
        Handle: 11
> HCI Event: Command Status (0x0f) plen 4                                                                                       #22 [hci0] 6.596994
      Authentication Requested (0x01|0x0011) ncmd 1
        Status: Success (0x00)
> HCI Event: Link Key Request (0x17) plen 6                                                                                     #23 [hci0] 6.597093
        Address: 17:05:16:03:35:E1 (OUI 17-05-16)
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22                                                                     #24 [hci0] 6.597162
        Address: 17:05:16:03:35:E1 (OUI 17-05-16)
        Link key: 42deb627ba26703e62d597d3fa119841
> HCI Event: Command Complete (0x0e) plen 10                                                                                    #25 [hci0] 6.598871
      Link Key Request Reply (0x01|0x000b) ncmd 1
        Status: Success (0x00)
        Address: 17:05:16:03:35:E1 (OUI 17-05-16)
> HCI Event: Auth Complete (0x06) plen 3                                                                                        #26 [hci0] 6.603100
        Status: PIN or Key Missing (0x06)
        Handle: 11
@ MGMT Event: Authentication Failed (0x0011) plen 8                                                                        {0x0001} [hci0] 6.603155
        BR/EDR Address: 17:05:16:03:35:E1 (OUI 17-05-16)
        Status: Authentication Failed (0x05)
= bluetoothd: profiles/input/device.c:control_connect_cb() connect to 17:05:16:03:35:E1: Invalid exchange (52)                             6.610825
< HCI Command: Disconnect (0x01|0x0006) plen 3                                                                                  #27 [hci0] 6.623558
        Handle: 11
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4                                                                                       #28 [hci0] 6.623982
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4                                                                                  #29 [hci0] 6.710499
        Status: Success (0x00)
        Handle: 11
        Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Device Disconnected (0x000c) plen 8                                                                          {0x0001} [hci0] 6.710560
        BR/EDR Address: 17:05:16:03:35:E1 (OUI 17-05-16)
        Reason: Connection terminated due to authentication failure (0x04)

This worked in old bluez versions (I think in buster with bluez 5.50) and it works in windows, too. Speaking of windows ... There is no need to enter any kind of PIN or Key. And also in the old buster days there was no Authentication required.

Hope this issue can be fixed soon.
If I can help with any additional logging / testing ... Please let me know.

[Wulfex]

Similar thing happened to me. I bought a PS4 controller to use, and after an update it would connect, then disconnect.

I found a work around tonight. It has to do with audio. I hooked my PS4 controller up via USB and found I could use it as a sound device in PulseAudio. If you go to the configuration tab in PAVC, and disable the controller as a sound device, then connect it via Bluetooth, it'll work. I'm guessing something similar probably happens to other controller that have jacks for headsets.

Might be some issue between PulseAudio, Pipewire and/or Bluez? Hope this helps!

[Krauzer94]

I am experiencing the same issue, and I've yet to find a controller that doesn't have this issue.

With two different computers and 4 different Bluetooth adapters, I have tried:

• 8bitdo's Ultimate C Bluetooth controller
• VOYEE's Switch controller
• Original PS3 controller
• Copycat PS3 controller
• Original Wii remote

The first four of these work over USB, and they all work over Bluetooth on older Bluez versions and on the latest version with ClassicBondedOnly=false set.

They'll connect over Bluetooth but aren't registered as evdev input devices, so no /dev/input/js* devices get created.

This workaround do not work for me, I tested it on two different devices:

1. Desktop with Fedora
2. Steam Deck with SteamOS

Changing the input.conf file did nothing for me, I restarted bluetooth service, restarted the device, and nothing changed, and the sad thing is that I just ordered a 8bitdo Ultimate C Bluetooth before I found out about this... I'm trying to cancel the purchase and I'm already looking into buying the regular version in which comes with the USB Dongle

[rs-gh-asdf]

@Krauzer94 I have this working with my 8bitdo Ultimate C Bluetooth controller by first pairing and then connecting as two separate actions.

[Krauzer94]

@rs-gh-asdf what about the PS3 controller?

Have you done something special besides the input.conf manipulation?

I do the following:

1. Connect it via Mini-USB
2. Go to bluetooth settings
3. Add a new device > select PS3 controller
4. Wizard starts to load > failed to connect

[rs-gh-asdf]

@Krauzer94 Sorry I don't have a PS3 controller so I can't test that. If you Ctrl+F this issue for PS3, PS4, or dualshock, some others have had success though.

[alexdelorenzo]

I am experiencing the same issue, and I've yet to find a controller that doesn't have this issue.
With two different computers and 4 different Bluetooth adapters, I have tried:

• 8bitdo's Ultimate C Bluetooth controller
• VOYEE's Switch controller
• Original PS3 controller
• Copycat PS3 controller
• Original Wii remote

The first four of these work over USB, and they all work over Bluetooth on older Bluez versions and on the latest version with ClassicBondedOnly=false set.
They'll connect over Bluetooth but aren't registered as evdev input devices, so no /dev/input/js* devices get created.

This workaround do not work for me, I tested it on two different devices:

1. Desktop with Fedora

2. Steam Deck with SteamOS

Changing the input.conf file did nothing for me, I restarted bluetooth service, restarted the device, and nothing changed, and the sad thing is that I just ordered a 8bitdo Ultimate C Bluetooth before I found out about this... I'm trying to cancel the purchase and I'm already looking into buying the regular version in which comes with the USB Dongle

I emailed 8bitdo about this issue in January and got this response:

Hi there,

The fix for this Bluetooth security bug prevents 8bitdo Ultimate C Bluetooth controllers from pairing via Bluetooth on Linux. See this issue on the BlueZ issue tracker.

Using BlueZ 5.70.0 or newer breaks compatibility with 8bitdo's Bluetooth controllers, as they rely on insecure pairing/connection methods that are now disabled by default.

Eventually, this will also affect Steam Deck users once Steam upgrades its BlueZ version.
Alex

Hi Alex,
Thank you for reaching us out!

The Ultimate C Bluetooth Controller is not compatible with Linux as it was originally made for Nintendo Switch ONLY.

kind regards,
8BitDo Support

As a result, I can't recommend the controller for use on Linux.

That said, I've been able to get it to work on Linux by doing the following:

1. Edit input.conf as explained by others above
2. Completely unpair and remove the controller from Bluetooth settings
3. Put the controller into Bluetooth pairing mode
4. Connect to the controller without pairing/trusting/remembering it
5. If the system remembers or trusts the controller, remove it completely before connecting again

At least on my end, going through the initial connecting process every time is the only way to get it to work over Bluetooth. If you try to connect to it again after pairing/trusting it, it will not work. I have to make the system forget about the controller entirely first and then connect.

[nfp0]

If you try to connect to it again after pairing/trusting it, it will not work. I have to make the system forget about the controller entirely first and then connect.

@alexdelorenzo Have you tried setting FastConnectable = true on /etc/bluetooth/main.conf or your user config file?
This fixed that problem for me on my Nintendo Switch controllers and now they always reconnect instantanously with no need to re-pair.

[alexdelorenzo]

@nfp0 Looks like I set FastConnectable = true a while ago and the issue persists

[Krauzer94]

I found the solution for the Playstation 3 controller (DualShock3) on this Gentoo wiki:

• https://wiki.gentoo.org/wiki/Sony_DualShock#DualShock_3

Worked with conjunction of the Arch wiki guide related to the /etc/bluetooth/input.conf:

• https://wiki.archlinux.org/title/Gamepad#Pairing_via_Bluetooth

What made the controller finally connect was the step where you are able to authorize the device, which was never triggered on my end while using my DE's system settings application, which for me is KDE Plasma.

[DavisNT]

Setting ClassicBondedOnly=false will also enable the CVE-2023-45866 security vulnerability.

For details see:

• https://ubuntu.com/security/CVE-2023-45866
• https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/profiles/input?id=25a471a83e02e1effb15d5a488b3f0085eaeb675

[Gravemind]

I had a game controller that, after pairing, did not have any joystick available (no /dev/input/js*). Setting ClassicBondedOnly to false helped, but then auto-connect didn't work after power cycle: it would connect then disconnect. I had to pair it each time. Also I wasn't comfortable with the security implications.

However, I found another workaround: I followed the steps for the Logitech BLE mouse with my game controller, and kept the default ClassicBondedOnly setting to true. I believe that the final unblock command was the key for me. It now auto-connects and works as expected.

Notes: I was unable to find the equivalent to bluetoothctl's unblock command in Blueman's GUI. I could not find much details about the unblock command (is it a bluetooth thing like pairing ? or a bluez thing ?), so I'm not sure if unblock compromises security as well...

(edit: bluez 5.72)

[alexdelorenzo]

On BlueZ 5.73, I can confirm that Bluetooth controllers work on my system again. I do not have to set ClassicBondedOnly=false. I've tried with two different Bluetooth adapters and several controllers. They work again on my end.

[VoodooCode14]

With an update of seemingly unrelated (no bluez*) packages, staying at 5.70 doesn't work anymore for me (Wii U Pro controller). While blueman-manager now replies with success after a connection, the controller seems to disagree (keeps flashing its lights).

However, sending a disconnect via blueman-manager turns the controller off .... so it appears there is some? connection...