psmoveapi
psmoveapi copied to clipboard
thp
Ubuntu 23.04: PS3 Move requests PIN, cannot be paired or connected
On Ubuntu 23.04 (Lunar Lobster), using KDE, and commit 3b7d9a0bc81ca71759e04d4d7bce6ed3d93eac2f I attempted to pair a PS3 Move (CECH-ZCM1E). Upon trying to connect, I received a request for a PIN. I have tried a PIN of 0000, not responding to the PIN prompt, and using bluetoothctl to make the connection. I have been unable to pair it. Thus, calibration is impossible. Unsure how to continue debugging the problem.
I did not get any further success with library version 4.0.5.
Firmware information for future reference (in case it is a firmware thing)
sudo ./psmove firmware-info
[PSMOVE WARNING] Magnetometer in 00:06:f7:de:5f:9c not yet calibrated.
Serial: 00:06:f7:de:5f:9c
firmware version: 0x0220, rev. 1829
BT firmware version: 0x0061
unknown bytes: 00 00 00 00 00 00 00
BlueZ version
t20kdc@Trevize:/media/modus/External2/psmoveapi/build$ bluetoothd --version
5.66
HCI is likely Bus 003 Device 004: ID 27c6:639c Shenzhen Goodix Technology Co.,Ltd. Goodix USB2.0 MISC
I assume you did a proper ./psmove pair that would write BlueZ config files?
Were the files in /var/lib/bluetooth/ properly created after that?
If pairing works, you shouldn't get a PIN query.
I assume you did a proper
./psmove pairthat would write BlueZ config files?Were the files in
/var/lib/bluetooth/properly created after that?If pairing works, you shouldn't get a PIN query.
I indeed did perform ./psmove pair.
root@Trevize:/media/modus/External2/alvr# tree /var/lib/bluetooth
/var/lib/bluetooth
└── 74:97:79:D6:0B:7A
├── 00:06:F7:DE:5F:9C
│ └── info
├── <censored>
│ ├── attributes
│ └── info
├── cache
│ ├── 00:06:F7:DE:5F:9C
│ ├── <censored>
│ └── <censored>
└── settings
5 directories, 7 files
00:06:F7:DE:5F:9C is the address of the PS3 Move.
I was still getting PIN queries.
After upgrading to Bookworm on the Raspberry pi (Debian 12 based), released October 2023, I'm seeing the exact same issue, plugging in controllers seems to pair them, then once you try to sync them, it asks for a PIN, 0000, and 1234, and blank do not have any effect and the controllers do not pair for the PS3 move controllers.
Just tested with Debian 11, bullseye, and the issue is appearing there as well, it seems like there was some bluetooth update that caused this to happen not too recently. Also to note, the PS4 controllers are having no issues, I was able to pair with them without any problems.
Here are two btmon traces with both the PS3 and PS4 controllers, we can see that the PS3 is asking for a PIN, and the PS4 is able to connect successfully. This was tested on a pi 4, running the latest bookworm OS
I found a previous pi with older code that still pairs and syncs correctly, and was not updated to the newest version. I was able to record the btmon for both initially pairing, and then syncing a PS3 controller for the first time with the older and newer code.
successful_initial_pair.txt unsuccessful_inital_pair.txt unsuccessful_inital_sync.txt successful_inital_sync.txt
Some initial observations for the initial pair on both: older had: AFH capable slave AFH capable master vs now AFH capable peripheral AFH capable central though this might just be a name change Older was using Handle 71, newer is using Handle 70 Authentication also is never successful on the new update, and is only pending:
< ACL Data TX: Handle 71 flags 0x00 dlen 16 #26 [hci0] 5.732582
L2CAP: Connection Response (0x03) ident 2 len 8
Destination CID: 64
Source CID: 64
Result: Connection successful (0x0000)
Status: No further information available (0x0000)
vs.
< ACL Data TX: Handle 70 flags 0x00 dlen 16 #27 [hci0] 8.569085
L2CAP: Connection Response (0x03) ident 2 len 8
Destination CID: 64
Source CID: 64
Result: Connection pending (0x0001)
Status: Authentication pending (0x0001)
The newer update also sends both a Link Key Request & Pin Code Request, which are both missing in the older btmon logs:
> HCI Event: Link Key Request (0x17) plen 6 #30 [hci0] 8.574823
Address: E0:AE:5E:4E:7A:C5 (ALPSALPINE CO,.LTD)
< HCI Command: Link Key Request Neg.. (0x01|0x000c) plen 6 #31 [hci0] 8.574885
Address: E0:AE:5E:4E:7A:C5 (ALPSALPINE CO,.LTD)
> HCI Event: Remote Name Req Complete (0x07) plen 255 #32 [hci0] 8.595870
Status: Success (0x00)
Address: E0:AE:5E:4E:7A:C5 (ALPSALPINE CO,.LTD)
Name: Motion Controller
> HCI Event: Command Complete (0x0e) plen 10 #33 [hci0] 8.596823
Link Key Request Negative Reply (0x01|0x000c) ncmd 1
Status: Success (0x00)
Address: E0:AE:5E:4E:7A:C5 (ALPSALPINE CO,.LTD)
> HCI Event: PIN Code Request (0x16) plen 6 #34 [hci0] 8.597813
Address: E0:AE:5E:4E:7A:C5 (ALPSALPINE CO,.LTD)
@ MGMT Event: PIN Code Request (0x000e)
also to note is the update from BlueZ 5.50 to 5.66
Great news!! I was able to get the PS3 controllers pairing and working correctly after installing bluez version 5.62 I followed this guide here: https://scribles.net/updating-bluez-on-raspberry-pi-from-5-43-to-5-50/
Installing versions earlier than 5.62 were not building correctly, this was the first version that did not encounter any errors in the build process.
it looks like version 5.66 is the culprit
Edit: tested with 5.65, and it works!
Do we know what change was the fix? Debian Bookworm has 5.66 so it would be nice to get the fix backported
I seem to have been reproducing this issue on my laptop running Ubuntu 22.04.4 LTS, which has bluez 5.64, and was able to resolve them by installing bluez 5.65 from src.
Which paints a slightly odd picture, if 5.62 and 5.65 are fine and 5.64 and 5.66 are not, that suggests it might be something weirder than a simple regression? If I get a chance I might try compiling some src versions of bluez to see if that gives a clearer picture. e.g. could it conceivably be a packaging configuration, and any default source built version, including 5.64 or 5.66 would be fine.
Yeah, seems like my suspicions were well founded. I've now tried installing bluez 5.62, 5.64, 5.65, and 5.66 from src, and every version worked just fine. So it seems like it isn't quite as simple as "bluez version was wrong", but I don't currently have any insight into what the problem actually is!
In case it ends up being relevant, I used this configure line in every case
./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var/
So, I've managed to do a bit more experimenting and searching, and feel maybe a bit closer to an explanation/solution.
So, first off, I'm no longer travelling, and was able to test on my (updated today) manjaro machine, and again, despite having connected move controllers to this machine before, I was not able to when I tried today. Very much appears to be the same issue.
So it's not distro specific, and it's not exactly bluez version specific. I did a bit of searching about to see if people with other bluetooth devices had been having similar issues, and found this which looked suspiciously similar https://github.com/bluez/bluez/issues/673 and reading that lead to reading this security vulnerability advisory https://github.com/advisories/GHSA-qjcj-xg77-6c32, and the fix to bluez config files here https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/profiles/input?id=25a471a83e02e1effb15d5a488b3f0085eaeb675
Changing /etc/bluetooth/input.cfg on my arch machine to use "ClassicBondedOnly=false" instead of the default of true does (after restarting bluez) eliminate this issue, making it possible to connect controllers without issue, and without compiling my own bluez!
Back on my ubuntu laptop, still with the custom-compiled bluez: With ClassicBondedOnly set manually to false I can connect fine, but with ClassicBondedOnly set to true I cannot connect. The settings file states that by default it is true, but the line actually setting it is commented out. So it seems likely (but I have not yet confirmed) that the built-in default configuration of the tested versions of the bluez source has ClassicBondedOnly set to false, but that patched versions in ubuntu or arch etc. have it set to true (and that my configuration files are in an odd place on my ubuntu machine having moved from in-distro bluez to a self compiled version).
So.. the workaround is "ClassicBondedOnly=false" in /etc/bluetooth/input.cfg
[ additional info edit ]
I have confirmed now that the default ClassicBondedOnly is false in the source versions of bluez I was testing earlier, and this makes a lot of sense, because they pre-date the fix. Several linux distributions, including Ubuntu seem to have back ported the security fix into their earlier, still active, versions of bluez, which makes sense, and explains some of the version confusion here in general. Others (like latest arch/manjaro) are bleeding edge enough for the current bluez to post-date the security fix.
What this means a bit more broadly is less clear. The security concern (that a malicious party can connect e.g. a bluetooth keyboard to a machine without it's user realizing, and then use that input to do 'bad things' on their computer) seems legitimate enough. So I suspect this is just how bluez configuration is gonna be setup from now.
Which means psmoveapi probably either needs a line about this issue in it's documenation somewhere, or else more challengingly something that detects/helps you with this situation at pair time? Presumably either way with some sufficiently visible warning to make it very clear that there is at least some associated security risk with doing so!
oh my. it works now. I already had the setting, so presumably I had to reboot, and not just restart bluetooth services? because I had tested that setting before and concluded that wasn't it.
Is there a way where we could add all the information to BlueZ' config so that the device would be as-if it was "classic bonded"? We already introduce the two devices with USB pairing, if there's just some data we don't write, we could maybe make it magically work with ClassicBondedOnly=true?