GNOME Bugzilla – Bug 603845
Use host address to create the wiimote pin code
Last modified: 2011-08-01 22:22:33 UTC
As per: http://wiibrew.org/wiki/Wiimote#Sync_Button Originally filed at; https://bugzilla.redhat.com/show_bug.cgi?id=544564 Discussion at: http://thread.gmane.org/gmane.linux.bluez.kernel/3961
Created attachment 149154 [details] [review] Use host address to create the wiimote pin code
Pin calculated from host address according to the above link works for me and the wiimote that was previuosly permanently paired with a Wii now automatically reconnects to the PC just pressing any key (tested with two different original wiimotes with 00:1F:C5 oui). For testing I hacked dbus-hci.c in bluez to send the needed bytes for my adapter (see attachment).
Created attachment 182017 [details] A working example of permanent pairing
The patch is reversed it seems. But the main problem from bluetoothd's point of view is that RequestPinCode() returns a string to bluetoothd, instead of an array of bytes. Otherwise we could add support for it right now in gnome-bluetooth.
Marcel mentions in: http://thread.gmane.org/gmane.linux.bluez.kernel/3961/focus=3964 That we should be able to do this solely in bluetoothd, hard-coding the behaviour from the VID/PID of the device.
Created attachment 183762 [details] [review] Use ho address to calculate pin code Slightly better patch, it doesn't hardcode the host address but it's still not suitable for applying on bluez since it's not conditional on vid/pid.
David Herrmann submitted a patch to do this directly in bluetoothd: http://thread.gmane.org/gmane.linux.bluez.kernel/12272 If it works for you, please close this bug, and report on the upstream mailing-list.
Actually, leave this bug opened, we'll need to remove the special-casing in the wizard's PIN code database.
Comment on attachment 149154 [details] [review] Use host address to create the wiimote pin code Munging should happen as per: http://git.kernel.org/?p=bluetooth/bluez.git;a=commitdiff;h=bbf21e61fbaa12532601f5f2b3d33a531ce590b5
Created attachment 187944 [details] [review] wizard: Use host address to create the wiimote pin Note that we only support pairing through the "Sync" button, not through the 1/2 buttons.
That patch works for me. I was able to pair a Wiimote, and have it reconnect to the computer after powering it off. We might want to tweak the pin code display code though, as the binary (and long) pincode is quite unsightly. Daniele, does this work for you?
Posted patch had a bug, but was tested with the fix on my local system. Attachment 187944 [details] pushed as a42beda - wizard: Use host address to create the wiimote pin
Created attachment 188066 [details] [review] Do not display the automatic pincode for Wiimotes Can we set automatic_pincode = TRUE to avoid displaying the long pincode? The patch you committed and with this other patch worked for me with 3 remotes.
Comment on attachment 188066 [details] [review] Do not display the automatic pincode for Wiimotes That'll do just fine, thanks! Attachment 188066 [details] pushed as b4368e6 - Do not display the automatic pincode for Wiimotes
According to: http://wiibrew.org/wiki/Wiimote#Bluetooth_Pairing the PIN is either: (a) The host MAC address, backwards (if pairing with battery button) (b) The wiimote MAC address, backwards (if pairing with (1)+(2) buttons) would it be enough to simple try one, then try the other? (A packet trace from a real Wii may hopefully show how the Wii knows which one to try first, or if it just always tries both anyway).
(In reply to comment #15) > According to: > > http://wiibrew.org/wiki/Wiimote#Bluetooth_Pairing > > the PIN is either: > > (a) The host MAC address, backwards (if pairing with battery button) > (b) The wiimote MAC address, backwards (if pairing with (1)+(2) buttons) > > would it be enough to simple try one, then try the other? (A packet trace from > a real Wii may hopefully show how the Wii knows which one to try first, or if > it just always tries both anyway). No, because the Wiimote will disconnect you as soon as the wrong PIN is passed.
This did not work for me after numerous attempts, and I could not determine why. Tracing the code it was properly detecting the wiimote but would not pair. I assume this is because bluez expects a null-terminated string and the binary nulls in the MAC address cause issues. However, this patch is made obsolete by David Herrmann's commit to bluez which adds wiimote detection/pin generation at a lower level. http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=1106efd440bf678c1422a9247b8c27f2259ac94b His patch worked for me first time and works very well with his kernel HID driver for the wiimote that's recently landed in linux-next and can be trivially backported to Linux 3.0 (likely earlier versions).
(In reply to comment #17) > This did not work for me after numerous attempts, and I could not determine > why. Tracing the code it was properly detecting the wiimote but would not > pair. I assume this is because bluez expects a null-terminated string and the > binary nulls in the MAC address cause issues. No, it doesn't, because we passed a string starting with a '$'. See: http://git.gnome.org/browse/gnome-bluetooth/tree/wizard/main.c#n795 > However, this patch is made obsolete by David Herrmann's commit to bluez which > adds wiimote detection/pin generation at a lower level. > http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=1106efd440bf678c1422a9247b8c27f2259ac94b Completely. And the code in gnome-bluetooth will be removed once the newer bluez version is tested. > His patch worked for me first time and works very well with his kernel HID > driver for the wiimote that's recently landed in linux-next and can be > trivially backported to Linux 3.0 (likely earlier versions).