Repository navigation
Ubuntu 23.04: PS3 Move requests PIN, cannot be paired or connected #489
Description
On Ubuntu 23.04 (Lunar Lobster), using KDE, and commit 3b7d9a0 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
Activity
thp commentedon Dec 17, 2023
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.
20kdc commentedon Dec 17, 2023
I indeed did perform
./psmove pair.00:06:F7:DE:5F:9Cis the address of the PS3 Move.I was still getting PIN queries.
adangert commentedon Feb 5, 2024
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.
adangert commentedon Feb 19, 2024
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.
adangert commentedon Feb 20, 2024
hcitrace-edit.txt
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
adangert commentedon Feb 20, 2024
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:
vs.
The newer update also sends both a Link Key Request & Pin Code Request, which are both missing in the older btmon logs:
also to note is the update from BlueZ 5.50 to 5.66
adangert commentedon Feb 20, 2024
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!
rpavlik commentedon Mar 22, 2024
Do we know what change was the fix? Debian Bookworm has 5.66 so it would be nice to get the fix backported
whitingjp commentedon Mar 25, 2024
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.
whitingjp commentedon Mar 25, 2024
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/
whitingjp commentedon Apr 10, 2024
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 bluez/bluez#673 and reading that lead to reading this security vulnerability advisory 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.
whitingjp commentedon Apr 10, 2024
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!
adangert commentedon Apr 10, 2024
Thanks for the investigation and find!
rpavlik commentedon Apr 12, 2024
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.
nitsch commentedon Apr 21, 2024
@whitingjp That was some major sleuthing. Thanks a lot!
thp commentedon Apr 24, 2024
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?thp commentedon Jun 15, 2025
As discussed in #457, it seems like unauthenticated HID devices were never a good idea to begin with from a security PoV, so this feature is probably never coming back. Having a Pi Pico W or even Pi Zero W act as in-between so that the host machine doesn't need to accept the PS Move as a system-level HID device and we can talk the application-specific host protocol with the Pi would probably be the best way forward (for all supported operating systems; the Pi Pico W/Pi Zero W can then talk any application protocol it wants over USB, and would itself accept the HID device or listen to L2CAP directly).
Alternatively, if the user is known to never use Bluetooth HID devices, one "safer" but potentially more involved way (and Linux/BlueZ-only) could be like what https://www.pabr.org/linmctool/linmctool.en.html was doing back in the day -- disable HID support in BlueZ, and listen to the L2CAP PSMs for HID directly.
20kdc commentedon Jun 15, 2025
just a heads-up - my PS3 Move device appears to have suffered a critical failure and I am no longer able to test.
something I will say however is that given both of these options sound like they need software engineering, and one of them requires hardware engineering; hardware is usually costlier (for both the user and developer) than software
tsibley commentedon Jan 30, 2026
The new-ish
CablePairingproperty may be useful here?tsibley commentedon Jan 30, 2026
Though that's not available until bluez 5.83.
thp commentedon Jan 30, 2026
Thanks, that's useful input, especially since the underlying issue talks about the Sixaxis (PS3 "normal" game controller), which basically has the same pairing mode as the PS Move: bluez/bluez#1165
For the sixaxis in particular, there seems to be: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=56516d6cc8d9 which calls
device_set_cable_pairing().It seems to support also the DS4, so maybe for BlueZ pairing, it might be enough to add pairing support to BlueZ for the PS Move: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/plugins/sixaxis.c?id=master#n134
Edit: Another link for future research into this https://git.kernel.org/pub/scm/bluetooth/bluez.git/log/?qt=grep&q=cable+pairing
soup587 commentedon Jul 26, 2026
is this planned to be addressed soon? i've noticed navigation controllers can pair just fine
adangert commentedon Jul 26, 2026
I'm testing things out right now, I might have found something that could help, looking into it
adangert commentedon Jul 27, 2026
@soup587 Still need to do more testing, but you might be able to test my custom branch for now to see if it helps: https://github.com/adangert/psmoveapi/tree/moved-linux-pairing-fixes, will be getting this up for a PR soon.