Closed carterDWatts closed 1 year ago
Thanks @kakra. Pretty sure we are going to be able to dissect the minimal requirements for this hardware.
It is really bizarre. Just testing:
Modules are loaded:
$ lsmod|grep algif
algif_hash 16384 1
algif_skcipher 16384 1
af_alg 32768 6 algif_hash,algif_skcipher
in bluetoothctl I can pair, trust and connect. I get:
[Xbox Wireless Controller]# connect F4:6A:D7:83:62:E4
Attempting to connect to F4:6A:D7:83:62:E4
Connection successful
I get:
[bluetooth]# connect F4:6A:D7:83:62:E4
Attempting to connect to F4:6A:D7:83:62:E4
[CHG] Device F4:6A:D7:83:62:E4 Connected: yes
Connection successful
[CHG] Device F4:6A:D7:83:62:E4 ServicesResolved: yes
[Xbox Wireless Controller]# info F4:6A:D7:83:62:E4
Device F4:6A:D7:83:62:E4 (public)
Name: Xbox Wireless Controller
Alias: Xbox Wireless Controller
Appearance: 0x03c4
Icon: input-gaming
Paired: yes
Trusted: yes
Blocked: no
Connected: yes
WakeAllowed: yes
LegacyPairing: no
UUID: Vendor specific (00000001-5f60-4c4f-9c83-a7953298d40d)
UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb)
UUID: Human Interface Device (00001812-0000-1000-8000-00805f9b34fb)
Modalias: usb:v045Ep0B13d0507
ManufacturerData Key: 0x0006
ManufacturerData Value:
03 00 80 ...
Battery Percentage: 0x32 (50)
[Xbox Wireless Controller]#
dmesg shows this:
[ 776.477064] xpadneo 0005:045E:0B13.000B: pretending XB1S Windows wireless mode (changed PID from 0x0B13 to 0x02E0)
[ 776.477068] xpadneo 0005:045E:0B13.000B: working around wrong SDL2 mappings (changed version from 0x00000507 to 0x00000903)
[ 776.477070] xpadneo 0005:045E:0B13.000B: report descriptor size: 283 bytes
[ 776.477072] xpadneo 0005:045E:0B13.000B: fixing up Rx axis
[ 776.477073] xpadneo 0005:045E:0B13.000B: fixing up Ry axis
[ 776.477073] xpadneo 0005:045E:0B13.000B: fixing up Z axis
[ 776.477074] xpadneo 0005:045E:0B13.000B: fixing up Rz axis
[ 776.477075] xpadneo 0005:045E:0B13.000B: fixing up button mapping
[ 776.477191] xpadneo 0005:045E:0B13.000B: gamepad detected
[ 776.477192] xpadneo 0005:045E:0B13.000B: enabling compliance with Linux Gamepad Specification
[ 776.477221] input: Xbox Wireless Controller as /devices/virtual/misc/uhid/0005:045E:0B13.000B/input/input53
[ 776.477428] xpadneo 0005:045E:0B13.000B: input,hidraw5: BLUETOOTH HID v9.03 Gamepad [Xbox Wireless Controller] on 34:c9:3d:b0:e5:d1
[ 776.477461] input: Xbox Wireless Controller Consumer Control as /devices/virtual/misc/uhid/0005:045E:0B13.000B/input/input54
[ 776.477524] xpadneo 0005:045E:0B13.000B: consumer control added
[ 776.477529] xpadneo 0005:045E:0B13.000B: controller quirks: 0x00000050
[ 776.477531] xpadneo xpadneo_welcome_rumble start
[ 777.467285] xpadneo xpadneo_welcome_rumble took 990ms
[ 777.467290] xpadneo 0005:045E:0B13.000B: Xbox Wireless Controller [f4:6a:d7:83:62:e4] connected
but there is no input, light continues to flash and after 2-3 minutes I lose connection anyway. So there must be something else missing there.
If I start from an empty bluetooth config, I can pair/trust the controller in bluetoothctl. When I press the small connection button on the controller, light flashes quickly and it rumbles. Btctl says connected: yes, however with no input. Light continues to flash quickly for a minute or 2, then light flashes slowly and btctl says Connected: no. I can redo this cycle many times (press, rumble, fast flash light, slow flash light), but without the connect/disconnect loop. However, if I switch off the controller off (main light off) or wait until it switches off automatically, then back on and retry connection by pressing the small connect button, this is when I enter the connect/disconnect loop (without rumbling this time). The only way to get out of it is to unpair and restart from scratch.
Could you run btmon
and watch the pair/connection process there? Also, look if you actually see button presses in btmon
.
@zebulon2 BTW, you seem to have a very different model of the controller, it has a OUI f4:6a:d7
while usually we see 44:16:22
for that model. xpadneo itself doesn't care but it may have a slightly different board or Bluetooth implementation.
@kakra : thanks. Interesting. On the package they say model 1914, but indeed there may be variations. I will do the monitoring tonight.
I did a lookup for both f4:6a:d7
and 44:16:22
and they both register to Microsoft Corp. I do not know if we should read too much into it, but there could be different boards indeed.
Hi, here are my btmon
test results:
At 29 seconds I start scan on
and do scan off
at 36.8 seconds.
At 48 seconds I issue the pair
command and the controller rumbles and connects. Light flashes fast then at 135 seconds disconnects (flashes slow).
I also join the btmon file: btmon_connect.txt
This is btmon
when having the connect disconnect loop:
The recurrent error messages are:
= bluetoothd: profiles/deviceinfo/deviceinfo.c:read_pnpid_cb() Error reading PNP_ID value: Request attribute has encountered an unlikely error 10.197357
= bluetoothd: profiles/deviceinfo/dis.c:read_pnpid_cb() Error reading PNP_ID value: Request attribute has encountered an unlikely error 10.197371
= bluetoothd: profiles/input/hog-lib.c:info_read_cb() HID Information read failed: Request attribute has encountered an unlikely error 10.197379
= bluetoothd: profiles/input/hog-lib.c:report_reference_cb() Read Report Reference descriptor failed: Request attribute has encountered an unlikely error 10.197385
= bluetoothd: profiles/input/hog-lib.c:report_reference_cb() Read Report Reference descriptor failed: Request attribute has encountered an unlikely error 10.197390
= bluetoothd: profiles/input/hog-lib.c:output_written_cb() Write output report failed: Request attribute has encountered an unlikely error
Any idea?
I also join the btmon file: btmon_loop.txt
I cannot see a problem on the first (non looping) report, this is weird.
Maybe those Error: Attribute Not Found (0x0a)
?
@zebulon2 you should use spoilers or gists for logs. It's kinda takes a lot of space
Same issues here. Initially, it would pair, connect, and rumble, but the light on the controller continued blinking and there was no input detected in jstest. Now, it just gets stuck in an endless connect/disconnect loop. I was able to find another bug report for the same issue here. The last comment has a workaround:
sudo btmgmt power off
sudo btmgmt privacy on
sudo btmgmt power on
But this doesn't work for me. I get an AuthenticationFailed error if I try to pair when privacy is enabled.
@zebulon2 you should use spoilers or gists for logs. It's kinda takes a lot of space
Thanks for the tip, I just did it. I also attached the btsnoop files.
Same issues here. Initially, it would pair, connect, and rumble, but the light on the controller continued blinking and there was no input detected in jstest. Now, it just gets stuck in an endless connect/disconnect loop. I was able to find another bug report for the same issue here. The last comment has a workaround:
sudo btmgmt power off sudo btmgmt privacy on sudo btmgmt power on
But this doesn't work for me. I get an AuthenticationFailed error if I try to pair when privacy is enabled.
Like you I cannot pair at all with privacy enabled
@ MGMT Event: Device Disconnected (0x000c) plen 8 {0x0001} [hci0] 20.736030
LE Address: F4:6A:D7:83:62:E4 (Microsoft Corporation)
Reason: Connection terminated by local host (0x02)
= bluetoothd: profiles/deviceinfo/deviceinfo.c:read_pnpid_cb() Error reading PNP_ID value: Request attribute has encountered an unlikely error 20.736208
= bluetoothd: profiles/deviceinfo/dis.c:read_pnpid_cb() Error reading PNP_ID value: Request attribute has encountered an unlikely error 20.736227
= bluetoothd: profiles/input/hog-lib.c:info_read_cb() HID Information read failed: Request attribute has encountered an unlikely error 20.736251
= bluetoothd: profiles/input/hog-lib.c:report_map_read_cb() Report Map read failed: Request attribute has encountered an unlikely error 20.736263
= bluetoothd: profiles/input/hog-lib.c:report_read_cb() Error reading Report value: Request attribute has encountered an unlikely error 20.736275
= bluetoothd: profiles/input/hog-lib.c:report_reference_cb() Read Report Reference descriptor failed: Request attribute has encountered an unlikely error 20.736290
= bluetoothd: profiles/input/hog-lib.c:report_read_cb() Error reading Report value: Request attribute has encountered an unlikely error 20.736300
= bluetoothd: profiles/input/hog-lib.c:report_reference_cb() Read Report Reference descriptor failed: Request attribute has encountered an unlikely error 20.736309
I attach the btmon file: btmon_privacy_on.txt
It is very strange: since I used privacy off with btmgmt, I can pair fo 2 seconds with a solid light but with no rumble. Then the controller blinks and goes directly to the disconnect loop. Maybe is there a setting retained in/var/lib/bluetooth
I need to investigate more.
It is very strange: since I used privacy off with btmgmt, I can pair fo 2 seconds with a solid light but with no rumble. Then the controller blinks and goes directly to the disconnect loop. I have deleted content of /var/lib/bluetooth
but I cannot pair anymore the way I did before. It is as if something had been retained in the controller or the bluetooth adapter!
It is as if something had been retained in the controller or the bluetooth adapter!
Yeah, I've suspected this multiple times in the past even for the older models. What usually helped was pairing the controller to a different computer, maybe even to the Xbox dongle, then go back to the system that had pairing problems. Let me know if you can confirm that.
Yeah, I've suspected this multiple times in the past even for the older models. What usually helped was pairing the controller to a different computer, maybe even to the Xbox dongle, then go back to the system that had pairing problems. Let me know if you can confirm that.
I just paired the controller with my Android smartphone, then paired again to my Linux PC. It is back to the first stage, where it successfully pairs and connects in bluetoothctl, rumbles, but the light remains blinking and there is no input. The infinite connect/disconnect loop is gone.
I just paired the controller with my Android smartphone, then paired again to my Linux PC. It is back to the first stage, where it successfully pairs and connects in bluetoothctl, rumbles, but the light remains blinking and there is no input. The infinite connect/disconnect loop is gone.
Yes, I had exactly the same experience: from the state where I have connection attempt without rumble, solid light for 1-2 seconds and then flashing light with Authentication error, I paired with my Android phone. Then I was back to the state I was able to pair and "connect" with rumble (but no input and flashing light), then disconnect. Under Android the controller is able to input moves. I can still trigger connect/disconnect loop then by trying to pair again from on off status (no light, then pressing the small button).
So there seems that we have two states when playing with connection on several machines, or using btmgmt power
options.
I think that this issue is a duplicate of #259. In the discussion of that issue, there is a proposed workaround which involves pairing the controller in Windows 10, and then copying the parameters to Linux. I was able to get the controller to work using this workaround. If you don't have Windows 10 on the same computer you could use a VM, but I chose to remove the SSD from a Windows 10 PC and insert it into the Linux PC I want to pair the controller with. Here was how I got it to work:
This is a very tedious workaround, but now I have the controller working perfectly in Linux. No lag, missed inputs, etc. Fortunately this only has to be performed once, as long as you don't reset the pairing on the controller. Obviously, this is some bug with the BlueZ pairing logic, because after it's paired it will connect and operate perfectly. I had no problems pairing it in Windows 10 or Android, only Linux. I am running Arch Linux with kernel 5.12.11 and BlueZ 5.59.
@stobb3s : amazing! Looking forward to testing this too. But it means that indeed there is some bug in Bluez in getting the keys which may be specific to our controller's model or sub-model. We should probably report this upstream to bluez then?
Can also confirm - this worked for me as well. The instructions in #259 and summarized by @stobb3s took about 10 minutes and spot on.
Ubuntu kernal 5.8.0.59 BlueZ 5.53 Xbox Controller model 1914
Would backing up the info file suffice to restore proper pairing in the future (in case the device is removed/unpaired)?
@zebulon2 The pairing requires a matching pair of keys in the controller and the Bluetooth stack to properly work. Restoring from backup works as long as the internal controller state didn't accidentally get modified between backup and restore, and I think the Bluetooth receiver MAC should also stay the same, so restoring to a new computer would probably not work: The Bluetooth receiver has to stay the same, this is why you need to pair with Windows on the same machine (however, pass-through of the Bluetooth hardware into the VM will work, although the VM and host system are technically not the same system).
After restore, you may need to purge the cache directory of the BlueZ service clean, so any non-matching cache info would be fetched again from the devices.
I think that this issue is a duplicate
I'm not sure if this is a duplicate. Careful comparison of the btmon dumps would be needed. There are at least two distinct instances of why the pairing fails, transplanting the keys cures both symptoms, but they may be caused by different issues.
But if someone would convert the solution into a Markdown-formatted guide to put in the docs folder, I'd happily accept a pull request.
We should probably report this upstream to bluez then?
Already done... All reports are listed in #198. You may go to the Bluez issues linked there and confirm the problem with additional information if you feel like you found some more clues.
Thanks all. However, I may not be doing it right. Still having the connect loop. At which moment do you unpair from Windows and pair again in Linux? It seems I lose my info file between the two, and the LTK has changed meanwhile.
@zebulon2 It's important to not unpair from Windows. Just turn the controller off, copy the keys, stop the bluez service in Linux, transplant the copied keys into it, then reboot Linux. The controller is now paired to both systems. This only works for the same receiver, it cannot work if the receivers are different hardware in Linux and Windows, thus it needs to be done on the same system (but you can use the VM for it with USB-passthrough for the Bluetooth receiver).
Thanks all. However, I may not be doing it right. Still having the connect loop. At which moment do you unpair from Windows and pair again in Linux? It seems I lose my info file between the two, and the LTK has changed meanwhile.
You don't unpair the controller from Windows. Pair it with Windows, then enter that into your info file in Linux. Then you simply turn on the controller by holding the guide button for 1 second. After you paired it Windows, you should not press the connect button again (at the top of the controller).
Thanks, I will try this. One thing I have noticed: my IRK in my info file is written little endian (backwards by 2 characters) whereas in the registry it is big endian. Is it the same for you? In the MisterTea guide on Archlinux forums, he copies the LTK in the same order than what he reads in the Windows registry. Could it be the problem? @stobb3s and @mark-4dollar , would you please have the time to dissect the minimum requirements to make the controller connect: add only the IRK? only the LTK? Do you really need to remove "Slave" and add Counter and Authentication=false? My EDIV and ERand are 0 in Windows, is it normal?
@zebulon2 This only works for the same receiver, it cannot work if the receivers are different hardware in Linux and Windows, thus it needs to be done on the same system (but you can use the VM for it with USB-passthrough for the Bluetooth receiver).
That was my mistake, sorry I did not spot this. Indeed I was using another Windows 8 laptop to connect. I understand that the LTK depends on the receiver MAC address then. Maybe this also explains the difference in endianness, but I am unsure about this one too. Unfortunately I have no dual boot at the moment on my machine, I will try something else soon.
I have no dual boot at the moment on my machine, I will try something else soon.
A qemu VM will do, you can easily and officially download a Windows 10 ISO from MS, install an evaluation copy (if you install without virtual networking, you can also skip the registration process if you prefer to), and then pass your Bluetooth receiver into the VM to do it.
Just a note: I tried kernel 5.13.1 on Archlinux and the controller still has the same connection issue. I read somewhere 5.13 fixed this but I cannot confirm it.
I have been able to finally pair and connect the controller to my Arch system, but circumstances are very strange, I did not have to edit the info file at all! This is what happened: I installed Windows 10 Pro (without key) on a QEMU/KVM VM. Unfortunately the Bluetooth passthrough (AX200 PCIe Intel, which provides Wifi and Bluetooth as a USB interface) did not correctly work (Driver Error, Code 10 - an error documented on the web). So I switched to VirtualBox and installed W10. In W10 I then succesfully installed the AX200 Bluetooth drivers from Intel. I activated BT on W10 and was able to pair and connect the controller to the W10 (solid light and working inputs).
Now the weird part: I just realised that I had removed the controller from the Archlinux host, hence I had no info file to edit, not even a /var/lib/bluetooth/[PC Bluetooth MAC]/[Controller Bluetooth MAC]
folder. So I switched off the W10 VM and the controller went also off. On my Archlinux box I scanned BT and pressed the pair button on the controller, leading to the fast flashing light. I was expecting the controller to vibrate and then not connecting properly as before. Actually it paired and connected succesfully, rumbling and then with a solid light! I looked at the /var/lib/bluetooth/[PC Bluetooth MAC]/[Controller Bluetooth MAC]/info
file and it contained standard Bluez config data, with no need to change [SlaveLongTermKey] to [LongTermKey] or to add anything under [IdentityResolvingKey]. The controller works perfectly, with no lag, and succesfully reconnects even after switching it off. It is as if the succesful connection to W10 VM had unblocked something. I have not tried to unpair/repair however.
I'm glad you were able to find a solution. It's true that I'm not certain that everything in my post was absolutely necessary, e.g. changing [SlaveLongTermKey] to [LongTermKey]. I was mostly just experimenting and wanted to share what worked for me.
So it appears that this information may also be stored inside the PC bluetooth chip itself, then.
No it's not stored in the chip. The dongle is pretty stateless: unplug it and it forgets everything. I assume the controller itself is not that stateless and stores/mixes information it should not.
I'm glad you were able to find a solution. It's true that I'm not certain that everything in my post was absolutely necessary, e.g. changing [SlaveLongTermKey] to [LongTermKey]. I was mostly just experimenting and wanted to share what worked for me.
So it appears that this information may also be stored inside the PC bluetooth chip itself, then.
Tanks @stobb3s for getting me on the right path anyway. It is always interesting to test. As @kakra points out, the issue certainly on the controller side, maybe the way keys are exchanged. Being a Microsoft product, one could think they have a peculiar way to implement that, maybe favouring Windows. That said, it connected fine with Android, which is a Linux after all. So maybe a combination of bluez and Linux issues there. Who knows. From experiments I could see that the controller could be in different states (plying with power settings for instance removed the rumble at connection time). I am pretty sure this issue will be identified at some point in the future.
This may also be an issue in bluez as I've found a case where a different ordering of HCI events during pairing would prevent bluez from accepting the pairing request. But I'm not sure if this should be fixed on the controller side (which MS is unlikely to do) or if this is a real problem in bluez (or we'd need a work-around to prevent the controller quirk). I confirmed this problem for the Xbox One S controller, I didn't check Xbox Series X|S yet:
The upstream report is here:
Well, the fact it was connecting to Android without issue makes me now think that there is nothing wrong with the BT implementation on the controller side. One could look into Android's handling of BT for more clues.
@zebulon2 Android uses different user-space tooling for Bluetooth (fluoride instead of bluez), so yes, it's probably not a kernel issue but that doesn't rule out bluez, neither it rules out the controller. In fact, you could also say that it works just fine in the Windows Bluetooth stack, so "nothing is wrong with the Bluetooth implementation in the controller". OTOH, it doesn't pair with iOS yet as far as I know. So that leaves us with bluez or the controller itself. At least for iOS, the controller packaging says that iOS support will come later. I'm not sure what this means, tho: Will iOS get an update, or will the controller get a firmware update?
Yes I see your point. At least Fluoride is open source, so if it connects with a "vanilla" controller, it means there is nothing obfuscated by Microsoft to prevent connection to competitors, which was my main concern.
worked with @stobb3s instructions at https://github.com/atar-axis/xpadneo/issues/295#issuecomment-874222979 ! Some notes:
info
file I meet the seem problem. And I can connect successfully by enabling LE Privacy:
sudo btmgmt power off sudo btmgmt privacy on sudo btmgmt power on
@YinXunzhe This seems more like a side effect and I do not generally recommend it. E.g., my XBXS controller actually refuses to connect reliably if privacy is enabled.
I'd rather recommend to purge the /var/lib/bluetooth/*/cache
directory empty and restart the Bluetooth service before trying to pair the devices.
Hey, I am having the same issue but @stobb3s's comment #295 (comment) did not resolve the issue for me. Editing the info file did have some effect, however, because now the controller changes modes wildly. When I turn it on and press the pairing button (so that the light blinks rapidly), the light is solid for a second the blinks slowly, then rapidly again and so on. At the same time, bluetoothctl loops "Connected: yes" and "Connected: no" all the time. I also have a device with a mac address starting with F4:6A:D7 if that is helpful information. Does anybody have an idea of what else I could try?
Ok, I did not read this comment and used the key data from a different computer that had windows installed.
I am trying to connect my xbox controller to a raspberry pi. So, I cannot install windows on the same machine and try and connect the controller to that windows installation. Does anybody have an idea how I can proceed?
If i understand it correctly, it could work if you had an USB-Bluetooth-Dongle and use that (both in windows to extract and on your pi to use) - i could be wrong though
SB-Bluetooth-Dongle and use that (both in windows to extract and on
Unfortunately, I do not own such a dongle.
The RPi Bluetooth support may be broken for this controller, it seems to depend on the model. You may want to try purging the bluez cache folder and remove the partially paired device, then upgrade bluez and kernel to latest versions (this includes a reboot), then try again. The controller works just fine here (except some tweaking is needed for latency and intervals in the bluez config).
sudo rpi-update
got me version 5.10.52-v7l+. This did not help, though. The behaviour is unchanged.
Using bluetoothctl the Xbox one X controller either enters a connect/disconnect loop or connects and even shows in jstest but disconnects when the controller leaves pairing move from a timeout. When the second of those two happens it vibrates when it says it is cconnected but the light does not stop fast blinking until it times out and disconnects. In jstest the controller shows on /dev/input/js0 but does not actually send any button presses. The controller works on android and is the most recent version, updated on Win 10.
I have already set disable_ertm to Y and have ControllerMode set to dual and tried with Privacy set to device in /etc/bluetooth/main.conf.
The output of
btmgmt info
showing that I have le and br/edr set:When I run
sudo dmesg | grep Bluetooth | grep Firmware
I getBluetooth: hci0: Firmware revision 0.0 build 118 week 15 2021
which I have confirmed with another person to be working for connecting the controller on the same model laptop (asus g14).Dmesg immedeatly after connecting:
Bluetoothctl once connected and once controllertimes out: