Pairing fails silently (?)

[N00byKing]

Version of xpadneo

Reported Version is v0.8-26-g041e8d8

Severity / Impact

• [x] I've read the docs and the bug reporting instructions
• [x] It does not work at all
• [ ] It used to work in a previous version
• [ ] It mostly works but sometimes it doesn't
• [ ] I found a work-around
• [ ] I probably didn't figure it all out but it's too early to give up
• [ ] I don't know how to ...
• [ ] It's too complicated
• [ ] Fantastic work but ...
• [ ] I can code and I want to help

Describe the bug

Following the given Instructions, when trying to pair it will report success, though the Controller never leaves pairing mode. If I still try to connect afterwards, I am greeted with the following:

Attempting to connect to 98:7A:14:98:A8:AD
Failed to connect: org.bluez.Error.NotAvailable

Trying to let the Controller auto-connect fails as well. An Interesting note is that the KDE Bluetooth Applet reports that the Controller is connected.

Full bluetoothctl Output:

[bluetooth]# scan on
Discovery started
[NEW] Device 98:7A:14:98:A8:AD Xbox Wireless Controller
[bluetooth]# pair 98:7A:14:98:A8:AD
Attempting to pair with 98:7A:14:98:A8:AD
[CHG] Device 98:7A:14:98:A8:AD Connected: yes
[Xbox Wireless Controller]# trust
[CHG] Device 98:7A:14:98:A8:AD Trusted: yes
Changing 98:7A:14:98:A8:AD trust succeeded
[CHG] Device 98:7A:14:98:A8:AD ServicesResolved: yes
[CHG] Device 98:7A:14:98:A8:AD Paired: yes
Pairing successful
[Xbox Wireless Controller]# connect
Missing dev argument
[Xbox Wireless Controller]# connect 98:7A:14:98:A8:AD
Attempting to connect to 98:7A:14:98:A8:AD
Failed to connect: org.bluez.Error.NotAvailable

System information

# uname -a
Linux doggo-pc 5.8.0-2-MANJARO #1 SMP PREEMPT Sat Aug 8 17:55:27 UTC 2020 x86_64 GNU/Linux

# xxd -c20 -g1 /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor | tee >(cksum)
xxd: /sys/module/hid_xpadneo/drivers/hid:xpadneo/0005:045E:*/report_descriptor: No such file or directory
4294967295 0

This makes me feel like I did something wrong, but I don't know what

Controller and Bluetooth information

I use a Laptop; sadly I don't know the Make/Model/Chipset of the Bluetooth card. It doesn't show up on lsusb

Looked it over, don't think it will help, but here is the requested dmesg output: xpadneo-dmesg.txt

[kakra]

Yes, there's some problem in the Bluetooth stack unrelated to the driver. We currently have no clue what's going wrong. The Linux Bluetooth stack seems to have problems authenticating the device or even fails to negotiate a link key for trust. The controller simply disconnects or vanishes, then tries to reconnect - but of course Linux would not accept that as the previous attempt didn't finish correctly.

There's currently no reliable work-around:

1. You could try a different Bluetooth dongle, even if it would be the same chipset brand, chances are that the hardware implementation is slightly different and makes thinks better (or worse).
2. Also, you could try stopping Linux Bluetooth services, then remove the device MAC from the database in /var/lib/bluetooth/HOST-MAC/DEVICE-MAC, then starting Bluetooth services again or reboot. Then try to connect the device again. It may work now.
3. You should check that the Linux Bluetooth service actually established the link key by looking at the files created in the previously mentioned directory. There should be an entry called "link-key=" in one of the files. If it is not, trust wasn't successful.
4. You could try removing the service cache of the Bluetooth service. It caches capabilities of discovered devices, and that may have gone incomplete for the gamepad. Removing it from /var/lib/bluetooth while the service is stopped will make it rebuild the cache by querying the gamepad.
5. Behavior is just nondeterministic. For example, my gamepad worked more or less reliably (after 5 to 30 seconds) after I swapped the dongle. I've not reset the Bluetooth stack by purging /var/lib/bluetooth clean and re-connected the gamepad. It now no longer auto-connects when turned on, I always need to click "connect" in KDE, sometimes multiple times, until it connects. So chances are that it works next time if you purge /var/lib/bluetooth and start over.
6. I found it may help clicking the connect button on the gamepad while btmon tries to connect (just briefly after starting pairing mode in Bluetooth). Clicking the connect button has some effect in the output of btmon and seems to generate some additional Bluetooth packets. But the effect may also be just placebo.
7. The gamepad often disconnects randomly during the auto-connect in Linux Bluetooth, submitting the connect command again (either by running connect in btctl or by clicking connect in KDE) in the right moment may work around this.

I've experimented with some settings of the Bluetooth services, and things may improve if you use the same settings, however there's no scientific evidence that it had a real effect. But you may try:

# /etc/bluetooth/main.conf
[General]
...
JustWorksRepairing = always

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

If you'd like to experiment yourself: I didn't try the Channels setting in [GATT] yet. Using 1 or 5 channels may make a difference.

But all in all, I think the Bluetooth implementation of the gamepad is somewhat buggy. And the Bluetooth implementation of Linux is too picky and not feature-complete. If you can dual-boot to Windows, it would be interesting to see how it behaves in Windows via Bluetooth. Also, while in Windows, I strongly recommend applying the latest firmware to the gamepad first using the Xbox app from the Windows store. I think it comes pre-installed with Windows 10. Otherwise, you should find a friend using Windows and apply the update from there.

After updating the firmware, it is almost always essential to clear the service cache directory of the Linux Bluetooth service as Microsoft seemed to have changed some parameters. Otherwise, you may see wrong button mappings or other odd behavior.

[kakra]

BTW: There's currently work going on in the background to unify xow and xpadneo into a set of native kernel drivers so we can work with the original dongle that comes with the controller. But there's a major show stopper which is the proprietary firmware needed to connect the gamepad, otherwise the dongle chipset is already supported in Linux: It's just a standard MT76 wifi chipset but with a hardware button for pairing and some additional firmware support to handle the pairing in the chipset. Apparently, the controller won't work or pair with standard wifi dongles or the standard driver.

[N00byKing]

Thanks for the Help, I really appreciate it.

I've attempted most of what you suggested, however I don't own a seperate bluetooth dongle at the moment, only the one integrated into my Laptop.

Sadly, I still didn't succeed in actually pairing the Controller. The Link Key was present, and from what I gathered from your comment it should indicate that it paired successfully. However, the Controller never left pairing mode, and I was unable to actually establish a connection. Additionally, I tried start/stopping the bluetooth service, deleting the files in /var/log/bluetooth/<Adapter Mac>, updating the Firmare, as well as setting JustWorksRepairing, but no dice.

It is however nice to see work on unifying xow and xpadneo! Hope upstreaming it won't pose a challenge.

Thanks again for your help

[kakra]

Does your kernel use Bluetooth as a module or built-in? Run lsmod to find the loaded modules. Everything starting with b is potentially about Bluetooth (except bpfilter and some others). If unsure, post the output of lsmod | grep '^b'.

[N00byKing]

Module, output (if still required) as follows

bnep                   28672  2
btusb                  65536  0
btrtl                  24576  1 btusb
btbcm                  20480  1 btusb
btintel                32768  1 btusb
bluetooth             720896  29 btrtl,btintel,btbcm,bnep,btusb,rfcomm

Edit: I found my Bluetooth USB ID. As for my defense for not finding it the first time, I am an idiot. xpadneo-lsusb.txt

[kakra]

Ah okay, that's always a good defense, well played. ;-)

Okay, could you check that you disabled ERTM for the bluetooth module? We had some reports lately that it didn't get disabled despite having the config option - which I'd attribute to a broken initrd creator which doesn't put the module parameters properly into the init ramdisk.

You can check it by looking at /sys/module/bluetooth/parameters/disable_ertm. If it says 'N', just write 'Y' to it: echo Y >disable_ertm.

[N00byKing]

I checked, it's disabled :c Sorry again for missing the USB ID

[kakra]

Maybe try also disabling ESCO (whatever that does), or try the inverse: Enable those options, try different combinations.

[N00byKing]

Tried all combinations, no change. Small Note: I am wondering why it is reporting "Connected: Yes" before actually pairing succeeds. No other Bluetooth Device I have does that

[kakra]

The controller uses simple secure pairing, in theory it doesn't need explicit pairing - just a connect request. OTOH, it behaves odd and nondeterministic. But that's not a driver issue with xpadneo itself, it's a problem somewhere in the Bluetooth protocol. Our driver has absolutely no influence on that: We cannot access the Bluetooth protocol from within xpadneo, we just get the HID protocol embedded inside.

[N00byKing]

I think I found a solution! At least partly... If I don't send pair, but instead trust and then connect it worked fine instantly However, I then run into an issue remarkably similar to #166. There is no Link Key. If I initiate pairing after connecting, the Link Key will appear.

Will report back after testing further.

EDIT: After pairing, the Controller loses connection again. But, after a reboot, it works perfectly (Controller autoconnected)! No issues at all anymore. Deleted my Bluetooth config to reproduce, works fine.

Short Version of what worked for me:

Enter pairing mode
Scan for Devices
Trust Controller
Connect Controller -> Controller will work from here, but disconnect instantly if not paired afterwards
Pair Controller -> Controller will no longer be connected. Reboot will cycle power to Bluetooth Adapter and fix the Issue
Reboot
The Controller autoconnects
???
Profit!

[kakra]

I'll reopen this, so we can put this into the documentation. Great find!

[kakra]

Apparently, it does not work for me: After running "connect", the controller connects and stays connected but no link key is written to the info file. Running trust, then pair, generates the link key and then I need to run connect manually. From now on, the controller cannot auto connect: It immediately cancels the connection when Linux requests link key authentication. Only when I run connect manually, it eventually passes the authentication request (but not always). I think there's something buggy in the firmware.

[N00byKing]

From what I read you ran trust after connect and pair, but I ran it first, before any other commands (save actually scanning). Running connect first it's expected to not get a link key at least in my case. However, running pair afterwards generates it. This disconnects the controller, but after rebooting (cause I got a laptop) it works fine. Note that I never run connect after the initial one. If thats not the case, I'd guess it depends on the Bluetooth Adapter used? I'm not well versed in the magical world of bluetooth on linux, so I'm just guessing

[kakra]

I tried your way, then described the only way that worked for me to get it connecting actually. But auto-connect does not work. It worked for me before until I reset my Bluetooth stack.

[N00byKing]

~~Bluetooth sucks~~

I'm currently away, will test further in a few hours. I'll have a different Bluetooth Adapter to test then too

[kakra]

BTW: It auto-connects, when I pair my controller with my Android phone. Some people found that a running desktop environment may disable auto-connect. FWIW, when I unplug the dongle and re-plug it, my gamepad immediately auto-connects successfully. There seems to be a small time frame before the desktop environment takes over and it just works that small moment.

[N00byKing]

Am now on my Workstation PC. Diagnostics:

uname -a
Linux Ryzen 5.8.2-arch1-1 #1 SMP PREEMPT Thu, 20 Aug 2020 20:45:00 +0000 x86_64 GNU/Linux

That one weird command that doesnt work on my laptop
00000000: 05 01 09 05 a1 01 85 01 09 01 a1 00 09 30 09 31 15 00 27 ff  .............0.1..'.
00000014: ff 00 00 95 02 75 10 81 02 c0 09 01 a1 00 09 33 09 34 15 00  .....u.........3.4..
00000028: 27 ff ff 00 00 95 02 75 10 81 02 c0 05 01 09 32 15 00 26 ff  '......u.......2..&.
0000003c: 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01 81 03 05 01 09  ...u.....%.u........
00000050: 35 15 00 26 ff 03 95 01 75 0a 81 02 15 00 25 00 75 06 95 01  5..&....u.....%.u...
00000064: 81 03 05 01 09 39 15 01 25 08 35 00 46 3b 01 66 14 00 75 04  .....9..%.5.F;.f..u.
00000078: 95 01 81 42 75 04 95 01 15 00 25 00 35 00 45 00 65 00 81 03  ...Bu.....%.5.E.e...
0000008c: 05 09 19 01 29 0b 15 00 25 01 75 01 95 0b 81 02 15 00 25 00  ....)...%.u.......%.
000000a0: 75 01 95 05 81 03 05 0c 0a 24 02 15 00 25 01 95 01 75 01 81  u........$...%...u..
000000b4: 02 15 00 25 00 75 07 95 01 81 03 05 0c 09 01 85 02 a1 01 05  ...%.u..............
000000c8: 0c 0a 23 02 15 00 25 01 95 01 75 01 81 02 15 00 25 00 75 07  ..#...%...u.....%.u.
000000dc: 95 01 81 03 c0 05 0f 09 21 85 03 a1 02 09 97 15 00 25 01 75  ........!........%.u
000000f0: 04 95 01 91 02 15 00 25 00 75 04 95 01 91 03 09 70 15 00 25  .......%.u......p..%
00000104: 64 75 08 95 04 91 02 09 50 66 01 10 55 0e 15 00 26 ff 00 75  du......Pf..U...&..u
00000118: 08 95 01 91 02 09 a7 15 00 26 ff 00 75 08 95 01 91 02 65 00  .........&..u.....e.
0000012c: 55 00 09 7c 15 00 26 ff 00 75 08 95 01 91 02 c0 05 06 09 20  U..|..&..u.........
00000140: 85 04 15 00 26 ff 00 75 08 95 01 81 02 c0                    ....&..u......
1461450476 1558

xpadneo-lsusb.txt From what I've seen this is the important bit: iProduct 2 CSR8510 A10

Sadly (or not, depending on the view) I can't reproduce your Issue. I followed the same steps as on my Laptop, (trust, connect, wait for disconnect, pair, reboot) and it works perfectly fine (except a bit slower because my adapter is a piece of junk).

The Adapter Model is: Fuck if I know... Says "LogiLink" tho. Looks exactly like the "LogiLink USB Bluetooth V4.0 EDR Class 1" on Amazon, can't guarantee it's the same tho

Sorry I'm not that much of a help diagnosing the Issue...

EDIT: Everything works including autoconnect

EDIT2: When setting it up, I ran into #166 again, but this time the "Connect, Disconnect, Connect, ..." loop bit. Went away when I disabled ERTM. Maybe it didnt disable correctly for him?

Last EDIT I swear: I did edit the bluetooth.conf on both my PC and Laptop. Enabled Auto Power on, set JustWorksRepairing. Did not do the reconnect thing you did tho

[ugly95]

FWIW, when I unplug the dongle and re-plug it, my gamepad immediately auto-connects successfully. There seems to be a small time frame before the desktop environment takes over and it just works that small moment.

I've noticed similar behaviour. I don't think I've tried unplugging my dongle and re-plugging it. But I have noticed that whenever I've restarted my computer with the XBox controller on, it always automatically connects just before I see my desktop. That's the only time I've had consistent success with automatic connections.

Otherwise, it automatically connects occasionally. Usually I have to send the connect command (using a bash script) to get it to connect. But even that doesn't work all the time. In bluetoothctl, I'll see a cycle of connected:yes and connected:no messages. I haven't tested thoroughly, but it seems to only connect if I send the connect command during the connected:yes message.

[N00byKing]

Re: Desktop Environment My PC uses sway, which doesnt have integrated bluetooth management, and, while my laptop uses KDE, I uninstalled bluedevil to manage connections myself

[lights0123]

I just got my new Series X / S controller, and am trying to make it work. Linux has no problem pairing it and I feel the connection rumble, but the light stays flashing rapidly and I don't get any gamepad data. I have ERTM disabled and these changes, but no link-key:

❱ cat /var/lib/bluetooth/my-mac/its-mac/info 
[General]
Name=Xbox Wireless Controller
Appearance=0x03c4
AddressType=public
SupportedTechnologies=LE;
Trusted=true
Blocked=false
WakeAllowed=true
Services=00000001-5f60-4c4f-9c83-a7953298d40d;00001800-0000-1000-8000-00805f9b34fb;00001801-0000-1000-8000-00805f9b34fb;0000180a-0000-1000-8000-00805f9b34fb;0000180f-0000-1000-8000-00805f9b34fb;00001812-0000-1000-8000-00805f9b34fb;

[IdentityResolvingKey]
Key=76373A796122164443DAEAEBCCED3776

[RemoteSignatureKey]
Key=76378DA3AC5E31ADEF9CAACBAC3D3776
Counter=0
Authenticated=false

[LocalSignatureKey]
Key=E0914028F86677464923AF5477090301
Counter=0
Authenticated=false

[LongTermKey]
Key=CD02B30B2C006ACD02B30B2C006ACD02
Authenticated=0
EncSize=16
EDiv=39
Rand=12899098137895635891

[SlaveLongTermKey]
Key=78ED393C4930414BCA4B1496D556F385
Authenticated=0
EncSize=16
EDiv=3109
Rand=1331738926223142593

[DeviceID]
Source=2
Vendor=1118
Product=2835
Version=1281

and lots of these, which seems to be the issue in #166:

< HCI Command: LE Start Encryption (0x08|0x0019) plen 28                                                                                             #8559 [hci0] 1285.974683
        Handle: 3585
        Random number: 0xb302cd6a002c0bb3
        Encrypted diversifier: 0x0027
        Long term key: cd02b30b2c006acd02b30b2c006acd02
> HCI Event: Command Status (0x0f) plen 4                                                                                                            #8560 [hci0] 1285.978574
      LE Start Encryption (0x08|0x0019) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 11                                                                                                            #8561 [hci0] 1286.064587
      LE Data Length Change (0x07)
        Handle: 3585
        Max TX octets: 251
        Max TX time: 2120
        Max RX octets: 251
        Max RX time: 2120
> HCI Event: Encryption Change (0x08) plen 4                                                                                                         #8562 [hci0] 1286.245597
        Status: PIN or Key Missing (0x06)
        Handle: 3585
        Encryption: Disabled (0x00)
< HCI Command: Disconnect (0x01|0x0006) plen 3                                                                                                       #8563 [hci0] 1286.245627
        Handle: 3585
        Reason: Authentication Failure (0x05)
> HCI Event: Command Status (0x0f) plen 4                                                                                                            #8564 [hci0] 1286.250593
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4                                                                                                       #8565 [hci0] 1286.289597
        Status: Success (0x00)
        Handle: 3585
        Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Device Disconnected (0x000c) plen 8                                                                                                 {0x0001} [hci0] 1286.289617
        LE Address: 44:16:22:ad:dr:es (Microsoft Corporation)
        Reason: Connection terminated due to authentication failure (0x04)
= bluetoothd: profiles/deviceinfo/deviceinfo.c:read_pnpid_cb() Error reading PNP_ID value: Request attribute has encountered an unlikely error                    1286.289806
= bluetoothd: profiles/input/hog-lib.c:info_read_cb() HID Information read failed: Request attribute has encountered an unlikely error                            1286.289821
= bluetoothd: profiles/input/hog-lib.c:report_map_read_cb() Report Map read failed: Request attribute has encountered an unlikely error                           1286.289830
= bluetoothd: profiles/input/hog-lib.c:report_reference_cb() Read Report Reference descriptor failed: Request attribute has encountered an unlikely error         1286.289846
= bluetoothd: profiles/input/hog-lib.c:report_reference_cb() Read Report Reference descriptor failed: Request attribute has encountered an unlikely error         1286.289860

[kakra]

This looks unfamiliar: There are actually six keys, I'm not sure what that means. It looks like strong authentication / encryption with asymmetric keys. You may need a very recent kernel to properly support this.

Also, bluetoothctl throws some strange profile errors. You may also need more recent Bluez libraries to supoort this controller. Do you own an Android phone and could try to pair it there? If it connects, try using the dpad to move the input focus on the Android screen: You should be able to navigate the menus with dpad, A and B.

[lights0123]

You may need a very recent kernel to properly support this.

Not a problem—I'm on Arch, running 5.9.6.

You may also need more recent Bluez libraries to supoort this controller.

Newer than 5.55-1?

Do you own an Android phone and could try to pair it there?

I do, but it didn't even show up in the Bluetooth devices list. It's still on Android Pie, though. I also tried on a Chromebook, which gave the same result as I experienced (computer thought that it paired, but the controller kept blinking and no controller input, and the connect-disconnect loop). This shows that at least it's not a problem with my computer as it also just uses BlueZ, but possibly defaults need to be modified.

If e.g. Android-x86 supports USB passthrough of a Bluetooth card, I can try that.

[lights0123]

Actually, nvm: I just tried again with my computer, and it just... worked?

[kakra]

I paired my controllers recently again, it resulted in the same behavior: Controller connected, paired, and immediately disconnected again. I managed to get that working again, probably with some luck, patience, and the right timing. Both my controllers (XB1S and XBE2) now pair again, even auto-connecting (tho, I have to wait for 30-60s until the connection establishes correctly).

What I did:

1. Run bluetoothctl on one console, use a second to check the contents of /var/lib/bluetooth to verify for link keys.
2. Stay in bluetoothctl to easily recall previous commands with the up arrow key.
3. Remove the controllers using bluetoothctl, if the controller tries to pair immediately again, run remove multiple times.
4. Pair the controllers to a different PC (Windows preferred) or Android to clear its internal Bluetooth state. It seems important that these other devices use a different Bluetooth stack: Windows and Android do, OSX or iOS probably do, too.
5. Try not to run scan on in bluetoothctl for the next commands unless the controller never shows up.
6. Check that the controller is actually removed from /var/lib/bluetooth.
7. Turn the controller on, prepair a pair XX:XX:... cmdline line in bluetoothctl, press the connect button.
8. Wait for the controller to be logged in bluetoothctl - could take 30s or so.
9. When it appears, immediately send pair ... followed by trust ...
10. It should show up in /var/lib/bluetooth with (link) keys.
11. If it doesn't try the steps again with a different timing.

The above steps did work for one controller but not the other. So I tried some different steps for the second one:

1. Use steps 1-6 from above.
2. Use KDE Bluetooth assistant to add a new device.
3. Turn the controller on, press the connect button.
4. Wait a few seconds until it shows up in the assistant dialog.
5. When it appears, use the assistant to pair it.
6. Check /var/lib/bluetooth for (link) keys.
7. If it didn't work, try the assistant again, but give it a manual PIN this time. Try 0000, 1234, or 9999.
8. You may need to retry a few times with different timings.

You may also try to pair it to your console again between repeating the steps to get the controller back into a clean pairing state. Also, check if the controller has some firmware updates available already: Every controller until today was released with a very buggy Bluetooth HID implementation, fixed later - sometimes months later.

After the keys appeared, the controller should be able to auto-connect after being turned on. May take 30-60s, tho.

Note: I've seen your latest comment while I was typing this. But I leave it as a reference to people who are seeing connection problems.

[kakra]

Actually, nvm: I just tried again with my computer, and it just... worked?

Pairing it to a different device temporarily may have done the trick. The Bluetooth implementation of the controllers is everything else but well-tested and stable. They are buggy as hell in Bluetooth mode even on Windows: Expect rumble to crash the controller.

[kakra]

You may need a very recent kernel to properly support this.

Not a problem—I'm on Arch, running 5.9.6.

Oh that famous Arch quote... 😁 haha

You may also need more recent Bluez libraries to supoort this controller.

Newer than 5.55-1?

I think 5.56 is to emerge soon, which has some more fixes and features.

[witty91]

Hi there, after the past two evenings of getting the controller to connect here's what worked for me:

1. disable ertm
2. enable JustWorksRepairing I tried that the first day, yesterday I ran a firmware update and that was the last bit to the puzzle here. Now the controller works pretty great! Edit: 3) run firmware update on the controller

[kakra]

Closing old Bluetooth issues, please report to the bluez project if the problem persists.