Can't connect xbox controller, (keeps disconnecting and connecting)

[felixsanz]

I have the common problem where the controller keeps doing this:

[CHG] Device 5C:BA:37:81:C3:DC Connected: yes
[CHG] Device 5C:BA:37:81:C3:DC Connected: no
[CHG] Device 5C:BA:37:81:C3:DC Connected: yes
[CHG] Device 5C:BA:37:81:C3:DC Connected: no

I have tried everything for many months, so now i'm finally asking for some help :(

disable_ertm is set to Y (I've tried N too, same result). I'm on 5.5.7 kernel but i've tried many kernels and some kernel modules for my rtl8822be chip.

One big problem is that I can't re-pair the device, whenever i type remove, the controller is automatically paired again!

[bluetooth]# remove 5C:BA:37:81:C3:DC
[DEL] Device 5C:BA:37:81:C3:DC Xbox Wireless Controller
Device has been removed
[NEW] Device 5C:BA:37:81:C3:DC Xbox Wireless Controller
[CHG] Device 5C:BA:37:81:C3:DC Modalias: usb:v045Ep02E0d0903
[CHG] Device 5C:BA:37:81:C3:DC UUIDs: 00001124-0000-1000-8000-00805f9b34fb
[CHG] Device 5C:BA:37:81:C3:DC UUIDs: 00001200-0000-1000-8000-00805f9b34fb
[CHG] Device 5C:BA:37:81:C3:DC ServicesResolved: yes
[CHG] Device 5C:BA:37:81:C3:DC Paired: yes
[CHG] Device 5C:BA:37:81:C3:DC ServicesResolved: no
[CHG] Device 5C:BA:37:81:C3:DC Connected: no
[CHG] Device 5C:BA:37:81:C3:DC Connected: yes
[CHG] Device 5C:BA:37:81:C3:DC Connected: no
[CHG] Device 5C:BA:37:81:C3:DC Connected: yes
[CHG] Device 5C:BA:37:81:C3:DC Connected: no
[CHG] Device 5C:BA:37:81:C3:DC Connected: yes
[CHG] Device 5C:BA:37:81:C3:DC Connected: no
[CHG] Device 5C:BA:37:81:C3:DC Connected: yes

If i type pair, i get this:

[bluetooth]# pair 5C:BA:37:81:C3:DC
Attempting to pair with 5C:BA:37:81:C3:DC
Failed to pair: org.bluez.Error.AlreadyExists

I don't know what else to do! I have 2 controllers that works fine on Windows but never worked on Linux. So frustrating so I hope someone could give me some direction.

Thanks!

[ugly95]

My first guess would be that you have the USB Bluetooth dongle issue that many people have. Unfortunately, this is not an xpadneo issue.

The best workaround I've found is to run this command after turning on you controller: echo -e 'connect 5C:BA:37:81:C3:DC' | bluetoothctl

Sometimes you have to use the command a couple times before it connects. It's easier if you put it into a script for easier access.

[felixsanz]

@ugly95 I don't get your answer. Why is that command going to help? I can type the command myself, it just doesn't work. Plus... i don't have an USB BT dongle! This is a realtek chip inside the motherboard

[ugly95]

For BT dongles that use CSR chipsets that command will help connect the controller when it doesn't connect automatically. I've had a lot of success with it.

Sometimes the command I posted doesn't work and I found that uninstalling and reinstalling xpadneo gets it going again.

I haven't heard of people having issues with a BT chip on the motherboard. Hopefully someone else can help you.

[felixsanz]

@ugly95 My controller connects automatically, it just disconnects automatically too

[alexideavila]

Do you have the controller in pairing mode? That was my issue at first. On the controller, hold down the small button between the bumpers and the xbox button will flash fast. Then you can follow the steps on the guide.

[felixsanz]

Do you have the controller in pairing mode?

Yes, of course.

[PetrusZ]

Same issue here.

[PetrusZ]

After a while connected, disconnect and reboot system, I got Failed to connect: org.bluez.Error.Failed here, even can't get connect again.

[Rixasha]

It seems to help me to turn ERTM off and comment out the lines having to do with module-bluetooth-discover from the pulseaudio config file and restart pulseaudio.

I'm wondering if it isn't some sort of a race with pulseaudio, or perhaps pulseaudio doesn't like ERTM being off.

[kakra]

Well, the Xbox One controller seems to have audio support (there's a headphone jack in the controller) but that doesn't seem to be exposed via BT so it should make no difference.

[Rixasha]

I only know that my controller pairing-loop-problem goes away if I just disable module-bluetooth-discover from pulseaudio, and it comes back if I re-enable it. I'm using a CSR8510 A10 -based bluetooth dongle.

[kakra]

@Rixasha That's interesting, I think I'm using the same... I'll try disabling it, let's see what result I get.

But when this fixes the problems, maybe even for other BT chipsets, then it may be a bug in the kernel BT stack. Today, I got a system freeze resulting from a GPF inside the kernel:

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

I wonder if that's related.

@atar-axis Maybe update the docs with this troubleshooting tip?

[kakra]

@Rixasha The interesting part: During system boot, that is, before my desktop is logged in (and thus pulseaudio and some other bluetooth stuff from the desktop) isn't running, the controller pairs/connects immediately. As soon as the desktop is running, even with the bluetooth modules removed from pulseaudio, it has difficulties connecting. So this isn't helping me, probably because of other BT running?

[ugly95]

@Rixasha The interesting part: During system boot, that is, before my desktop is logged in (and thus pulseaudio and some other bluetooth stuff from the desktop) isn't running, the controller pairs/connects immediately. As soon as the desktop is running, even with the bluetooth modules removed from pulseaudio, it has difficulties connecting. So this isn't helping me, probably because of other BT running?

I've actually noticed the same thing. If I turn my controller on while my computer is booting, it connects immediately when I see the Desktop (I use auto-login, so I'm not exactly sure at which point the connection happens).

But I have the connection issues after the Desktop is running. And, as I mentioned above, issuing connect in bluetoothctl usually gets the controller to connect (sometimes I have to issue the command two or three times). This is also with a CSR dongle.

[kakra]

@ugly95 Using auto-login, too. But I'm sure the connection is established before any DE component loads because I have a two-stage boot process, one of which being a reduced environment that only does prelinking[1] while nothing else except essential services are running, and after this phase it reboots. Bluetooth becomes auto-activated in this phase due to plug & play and systemd, and already at this early/reduced stage, the controller connects. I can confirm that in both my boot stages (reduced and full) the controller immediately connects in the early boot phase.

[1]: I'm doing this because prelink won't touch any libs or executables already mapped into memory.

[kakra]

Running sudo btmon and try letting the controller auto-connect sheds some light on this:

> HCI Event: Command Status (0x0f) plen 4                                                                                                                                                                                                  #20 [hci0] 7.162538
      Remote Name Request (0x01|0x0019) ncmd 1
        Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                                                                                                                                     #21 [hci0] 7.163535
        Num handles: 1
        Handle: 75
        Count: 1
> HCI Event: Remote Name Req Complete (0x07) plen 255                                                                                                                                                                                      #22 [hci0] 7.182547
        Status: Remote User Terminated Connection (0x13)
        Address: C8:3F:26:A9:2D:6C (Microsoft Corporation)
        Name: 
@ MGMT Event: Device Connected (0x000b) plen 18                                                                                                                                                                                       {0x0002} [hci0] 7.182567
        BR/EDR Address: C8:3F:26:A9:2D:6C (Microsoft Corporation)
        Flags: 0x00000000
        Data length: 5
        Class: 0x000508
          Major class: Peripheral (mouse, joystick, keyboards)
          Minor class: 0x02
@ MGMT Event: Device Connected (0x000b) plen 18                                                                                                                                                                                       {0x0001} [hci0] 7.182567
        BR/EDR Address: C8:3F:26:A9:2D:6C (Microsoft Corporation)
        Flags: 0x00000000
        Data length: 5
        Class: 0x000508
          Major class: Peripheral (mouse, joystick, keyboards)
          Minor class: 0x02
> HCI Event: Disconnect Complete (0x05) plen 4                                                                                                                                                                                             #23 [hci0] 7.316564
        Status: Success (0x00)
        Handle: 75
        Reason: Remote User Terminated Connection (0x13)
@ MGMT Event: Device Disconnected (0x000c) plen 8                                                                                                                                                                                     {0x0002} [hci0] 7.316589
        BR/EDR Address: C8:3F:26:A9:2D:6C (Microsoft Corporation)
        Reason: Connection terminated by remote host (0x03)
@ MGMT Event: Device Disconnected (0x000c) plen 8                                                                                                                                                                                     {0x0001} [hci0] 7.316589
        BR/EDR Address: C8:3F:26:A9:2D:6C (Microsoft Corporation)
        Reason: Connection terminated by remote host (0x03)
= bluetoothd: Can't get HIDP connection info                                                                                                                                                                                                         72.171013

For some reason the connection seems successful initially but then the controller initiates a disconnect after this command:

> HCI Event: Remote Name Req Complete (0x07) plen 255

This is nothing that xpadneo could prevent. I'm not familiar with the bluetooth protocol and it quirks and details. Maybe someone else knows what may be going on and if this would be fixable in the kernel or the bluez daemon.

[kakra]

I did some further digging... The line in question actually indicates that the controller is requesting a link key from us. Looking at the device database in /var/lib/bluetooth I found that the device actually had no link key stored:

# cat /var/lib/bluetooth/00:1A:7D:DA:71:15/C8:3F:26:A9:2D:6C/info
[General]
Name=Xbox Wireless Controller
Class=0x000508
SupportedTechnologies=BR/EDR;
Trusted=true
Blocked=false
Services=00001124-0000-1000-8000-00805f9b34fb;00001200-0000-1000-8000-00805f9b34fb;

[DeviceID]
Source=2
Vendor=1118
Product=765
Version=2307

Thus, I removed the device using the BT desktop applet. Also, I went to /etc/bluetooth/main.conf and adjusted the following settings and restarted the bluetooth service:

[General]
Class = 0x000100
FastConnectable = true
JustWorksRepairing = always

[GATT]
ReconnectIntervals=1,1,2,3,5,8,13,21,34,55
AutoEnable=true

Not sure if all these are needed, FastConnectable, JustWorksRepairing, and AutoEnable may be the important settings.

Now I re-paired the controller using the wizard of the desktop applet instead of just choosing the controller from the list of visible devices. That may have done the trick of correctly adding the link key:

# cat /var/lib/bluetooth/00:1A:7D:DA:71:15/C8:3F:26:A9:2D:6C/info
[General]
Name=Xbox Wireless Controller
Class=0x000508
SupportedTechnologies=BR/EDR;
Trusted=true
Blocked=false
Services=00001124-0000-1000-8000-00805f9b34fb;00001200-0000-1000-8000-00805f9b34fb;

[LinkKey]
Key=2165869449E599576DD1D76A6ACFD34E
Type=4
PINLength=0

[DeviceID]
Source=2
Vendor=1118
Product=765
Version=2307

[jonahnm]

sudo nano /etc/modprobe.d/bluetooth.conf

That command launches the CLI-based text editor and either creates the config file you need, or opens an existing one. Now type the following line into the config file:

options bluetooth disable_ertm=1

try doing that it might work

[jasondaigo]

let me hop on the train. i did the ertm thingy and it doesnt work for me after Xorg start(i3 here). led indicates conected and disconnected randomly; but it never connected funlly, pairing works, but the issue is gone if i connect with bluetoothctl on TTY before starting xorg. using programs and sound seems to not interrupt then if connected. what does xorg(or pulse) do with bluetooth that it refuses to connect? i can not use any wizard like kakra cause its already on X

[kakra]

Pulseaudio will use Bluetooth audio devices. Maybe it helps disabling that in /etc/pulse/default.pa:

### Automatically load driver modules for Bluetooth hardware
.ifexists module-bluetooth-policy.so
#load-module module-bluetooth-policy
.endif

.ifexists module-bluetooth-discover.so
#load-module module-bluetooth-discover
.endif

FWIW: While the gamepad has audio support, that function is not announced via Bluetooth, only when using the original Xbox dongle.

[jasondaigo]

ah too bad cant test any longer, controller is not connecting anymore at all. i guess i stick to xow again. just not worth the frustration. maybe there are too many cheap usb adapter around which mess up peoples gaming joy :-)

staysafe

[deathxxx123]

I have zero problems with my controller. Xbox One S, XanMod kernel +

# edit /etc/default/grub
# and add the kernel flag
# "bluetooth.disable_ertm=1"
# to the GRUB_CMDLINE_LINUX line.
# Then run
# 'sudo grub-mkconfig -o /boot/grub/grub.cfg'
# and reboot

Ubuntu 20.04, XpadNeo v.0.7 (my mistake. it's v0.9-1-g84cabe9) Bluetooth & WiFi combo: Intel Corporation Wireless-AC 9260

[Vladius25]

Can't connect Xbox Series X wireless on Fedora (5.9.13-200.fc33.x86_64). Keeps connecting and diconnecting. I have ertm disabled. What i can see in system logs:

bluetoothd[803]: profiles/input/hog-lib.c:report_map_read_cb() Report Map read failed: Request attribute has encountered an unlikely error
bluetoothd[803]: profiles/input/hog-lib.c:report_reference_cb() Read Report Reference descriptor failed: Request attribute has encountered an unlikely error
bluetoothd[803]: profiles/input/hog-lib.c:report_reference_cb() Read Report Reference descriptor failed: Request attribute has encountered an unlikely error
bluetoothd[803]: profiles/battery/battery.c:batt_io_ccc_written_cb() Battery Level: notifications not enabled Request attribute has encountered an unlikely error

[kakra]

Can't connect Xbox Series X wireless on Fedora (5.9.13-200.fc33.x86_64). Keeps connecting and diconnecting.

It's failing at the Bluetooth level already, before xpadneo is even considered as the driver. You may want to try a different Bluetooth dongle, or upgrade the controller firmware using Windows first. Then, maybe pair the controller once in Windows Bluetooth, then try again in Linux.

The Bluetooth pairing problems should probably reported to the Bluez team: http://www.bluez.org/contact/

We are seeing a lot of pairing problems for all models of the Xbox controllers with Bluez while there seem to be no problems with using fluoride (the Android stack, derived from the same code that the Switch consoles use which also show no pairing problems). So I suggest this boils down to the Bluez stack.

It's important to differentiate from the crashes of the firmware caused by using rumble commands. This even happens in Windows. Only issues about initial pairing and connect should be reported to Bluez.

[T-Zeros]

I had similar issues with connecting a XBOX Series X Wireless to a Raspberry Pi 3B+. I got it to load the driver correctly and even got the rumble during the first pairing, but the X did not light up constantly. Later connection attempts resulted in the "Connected yes/no" cycle.

The solution to this is to add "Privacy=device" to /etc/bluetooth/main.conf under the [General] section. After that restart the bluetooth service (sudo systemctl restart bluetooth). I also removed the controller in bluetoothctl and repaired it again, not sure if this is necessary. After that it works without problems!

Kudos to this reddit post: https://www.reddit.com/r/linux_gaming/comments/js0trh/anyone_get_the_xbox_series_x_controller_to/gddwyjk?utm_source=share&utm_medium=web2x&context=3 where I have the solution from.

[kakra]

The solution to this is to add "Privacy=device" to /etc/bluetooth/main.conf under the [General] section.

Great find, I wonder if this has any other implications. I'll add that to my test settings and if it generally works, I'll add it to the docs.

[Vladius25]

Works for me

[DecafSlurper]

"Privacy=device" to /etc/bluetooth/main.conf under the [General] section.

I have tried this on a Raspberry PI3B+ with Retropie 4.7.1 with an XBox Wireless Controller (M.Nr. 1914) and sadly it does not seem to work for this combination.

The first problem was trying to enable privacy, which required this fix. However, even with privacy enabled and after multiple power cycles, bluetoothctl remove, pair, trust, connect cycles (with varying order of commands), with/out deleting the bluetoothd cache in /var/lib/bluetooth the initial pairing still failed and a subsequent connect sent bluetoothd into a connect/disconnect cycle.

[kakra]

@DecafSlurper Try pairing your controller to a different Bluetooth adapter first, i.e. to your mobile phone.

[DecafSlurper]

@kakra thank you for the suggestion. Before, I have paired the controller with a Windows PC for a firmware update, worked fine. Following your suggestion I have just paired it with an Android phone which worked like a charm, and then immediately afterwards tried it with my Raspberry Pi, no dice, same problem. I do notice that after trying to connect the controller to my Raspi I have to re-pair it with Windows for the PC to find the controller.

Ideas left to try out:

• Try with a different Bluetooth controller (the one from the PC)
• Try out not yet explored suggestions from this thread, like JustWorksRepairing

[kakra]

TBH, the Bluetooth implementation of the controller seems to be very bad (maybe not at the protocol facing layer but at the depending layers in the firmware). But Linux Bluez does not seem to be much better, as it seems to miss some features or their implementation is flawed (Android uses the standard Bluetooth kernel code as I could figure out but it uses a different user-space daemon "fluoride" instead of Bluez).

[DecafSlurper]

Tried it with a different Bluetooth dongle on the Raspberry Pi 3B+ and it works like a charm, so this seems to be Bluetooth controller specific. However, the on-board Bluetooth controller of the Raspberry Pi does work with other Bluetooth devices (keyboard, mouse also Microsoft now that I think of it).

@kakra Given your assessment of the Bluetooth implementations of the controller and bluez, I wonder if it would work with Android's fluoride stack. That could help isolate the problem (driver, bluez).

[kakra]

@DecafSlurper Yeah, I already pulled the sources but the build system is outdated while at the same time it requires a hell of latest dependencies. So I haven't been able to make a runnable binary. But that actually has been my original idea.

The dongle hardware itself definitely has an impact on this, even the same chipset (the very common CSR in my case) may work differently when the dongle was built by different manufacturers. I think there are different revision of this chipset, and probably even fake China chipsets, with some tiny different nuances that can make the controller behave differently. Also, changes in the kernel for the Bluetooth drivers made differences (e.g. turning off ERTM makes a difference while it shouldn't, i.e. we can leave ERTM on when putting a patch into the L2CAP handler). But I'm pretty sure by now that the biggest impact comes from the Bluetooth stack: Finally, that's the software that handles the negotiation of keys and pairings. And Bluez seems to do something here that the controller doesn't like: The disconnect that happens is due to the controller initiating a disconnect actively because it doesn't like the authentication. But sometimes it works for like 30s, then it breaks. Some other times, it may even just work and the connection is stable. It's probably some order of protocol opcodes that the controller doesn't like, or a timing issue. But I'm not sure which side is wrong because most other Bluetooth devices work just fine. But OTOH, the controller works just fine with all other Bluetooth implementation except Bluez.

[Kzimir]

add "Privacy=device" to /etc/bluetooth/main.conf works for me too :D

[Kzimir]

I have two laptop and each have a Realtek bluetooth device. The device recognize the XBpx gamepad but connect/disconnect constantly. If i use a dongle USB BT, i have no issue to pair/connect my XBox pad.

[RobertoGarciaCarrillo]

Try inserting the dongle on another usb port, that worked for me

[kakra]

The controller needs ERTM to pair properly (see also #272) but the current kernel won't accept it in ERTM mode unless the L2CAP patch is included in the kernel. When the patch is in, it seems to additionally need a proper authentication agent which bluetoothctl itself doesn't provide (at least I found no solution yet) but the KDE Bluetooth applet pairs the controller just fine.

[Logical-sh]

Hi! I have a 1915 model, and no combination of settings has EVER gotten it to reliably connect. I can get it to connect immediately to my windows work pc or my android phone. On my linux desktop (KDE or bluetoothctl) no matter which of the posted settings, or the ERTM is on or off (I also patched my kernel to try that) the controller will kinda connect once if "Privacy = off" but it never fully initializes (light still blinks and it doesn't work anywhere.) Then if I let the controller reboot it just infinately connect loops. If Privacy = device it just constantly asks me for permission to connect.

[kakra]

Does Privacy = device at least successfully connect the controller after confirmation?

[Logical-sh]

No, it just asks over and over. (Edit: Disabled Scan) controller-connect.log Here is the btmon of device privacy, I turned on scanning and did connect 44:.....

This is with device privacy and JustWorks enabled. It looks like it didn't generate keys.

[Logical-sh]

I then tried to pair from the pc, instead of connecting from the PC. (Edit: Disabled scan and recaptured.) controller-pair.log

[kakra]

The pair log seems to connect but then immediately drops the connection again. The connect log seems to be stuck at authentication. I do not know much about the inner workings of Bluetooth but here it looks like the direction of the initiator seems to make a difference.

BTW: I was never able to successfully pair the controller using only bluetoothctl. I need to use the KDE Plasma Bluetooth widget instead which pairs the controllers just fine when using the "Add new device" wizard. But it's important to remove the controller from the Bluetooth daemon first, so it has no previous knowledge of it. It may also be needed to pair the controller first to a different system so it overwrites its knowledge of your PC. You could try pairing it to your smartphone to do that.

[Logical-sh]

Well this is weird. I have reset this device using android many times, but I connected it to windows to get a packet capture, Then reconnected to linux, it failed. Got a capture of that, then reconnected to linux with default settings and it just worked right away. (DISABLED device privacy and link repair for that.) I can upload the pcaps if you think they might be helpful? I can find no rhyme or reason as to why this suddenly worked like this haha.

[kakra]

This is another instance of an example that makes me believe that the controller does not properly clean up its internal state when connecting to different devices. It's just that if you find the "right" other device, you can get into a state that it properly connects again...

[Kzimir]

Good news, i have a XBox Series X gamepad. I install xpadneo git + set "Privacy=device" to /etc/bluetooth/main.conf I built kernel 5.11.10 + L2CAP patch from #272 and now the gamepad pair and connect correctly with my Realtek bluetooth.

[kakra]

Did you enable ERTM for that matter? It may be possible that we could skip "Privacy=device" and just use the L2CAP patch what 5.12+ kernels will have. Leaving ERTM on may change how the controller depends on "Privacy=device". Also, being able to properly use ERTM works around rumble issues with the controller, so I have patched queued that remove the ERTM work-around from xpadneo.

[Kzimir]

No ERTM is disabled in /sys/modules/Bluetooth/... I’ll try to disable « Privacy = device » when I’ll come back to the PC

[Kzimir]

I confirm that ERTM disabled + skip "Privacy=device" works. To resume, L2CAP patch is enough for :-)

[kakra]

Thanks, I assume disabling ERTM somehow affects how the controller behaves during pairing although those options are not related. Since the L2CAP patch will be in kernel 5.12, we are going with ERTM enabled (which the kernel default anyways) and can skip Privacy=device (which isn't default).

So I assume it is safe to say that this will be fixed by kernel 5.12?

[Kzimir]

It will be better to wait the final release for Kernel 5.12 before to close this BR and others tests from users here.