Apple Magic Trackpad requires PIN to pair, fails manual pairing

Bug #618838 reported by Fabián Rodríguez
190
This bug affects 36 people
Affects Status Importance Assigned to Milestone
bluez (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: bluez

The Apple Magic Trackpad requires a PIN to pair upon first activation. Such PIN is '0000' which can be entered on a regular keyboard. Once connected, it also requires granting authorization to connect again. See the two attachments for such dialogs.

When trying to setup this device manually (after moving it from another system, for example), by default Ubuntu will propose a random 6-number PIN, which can't be entered on the trackpad, which then means pairing fails.

This trackpad should connect automatically, although I don't personally know enough about bluetooth to suggest how this should happen.

I have documented a workaround to pair this device here:
https://wiki.ubuntu.com/Multitouch/AppleMagicTrackpad

Once paired the device does not need pairing each time the system is used / restarted, it will remember it.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: bluetooth (not installed)
ProcVersionSignature: Ubuntu 2.6.35-15.21-generic 2.6.35.1
Uname: Linux 2.6.35-15-generic i686
Architecture: i386
Date: Mon Aug 16 15:24:53 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Alpha i386 (20100812)
InterestingModules: rfcomm sco bnep l2cap btusb bluetooth
MachineType: Acer Aspire R1600
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-15-generic root=UUID=30841bc6-7bfc-4ffb-8b7c-60772f799265 ro nosplash
ProcEnviron:
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: bluez
dmi.bios.date: 06/17/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P01-A1
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: FMCP7A-ION
dmi.board.vendor: Acer
dmi.chassis.type: 3
dmi.chassis.vendor: Acer
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP01-A1:bd06/17/2009:svnAcer:pnAspireR1600:pvr:rvnAcer:rnFMCP7A-ION:rvr:cvnAcer:ct3:cvr:
dmi.product.name: Aspire R1600
dmi.sys.vendor: Acer
hciconfig:
 hci0: Type: BR/EDR Bus: USB
  BD Address: 00:0F:3D:3D:7C:5C ACL MTU: 192:8 SCO MTU: 64:8
  UP RUNNING PSCAN
  RX bytes:7619 acl:369 sco:0 events:124 errors:0
  TX bytes:551 acl:12 sco:0 commands:50 errors:0
rfkill:
 0: hci0: Bluetooth
  Soft blocked: no
  Hard blocked: no

Revision history for this message
Fabián Rodríguez (magicfab) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in bluez (Ubuntu):
status: New → Confirmed
Revision history for this message
kernst (kernst) wrote :

I did not find that Maverick prompted me with an "Always grant access" checkbox as shown in the referenced wiki article, so the pairing was still lost between reboots.

I was forced to use the instructions in http://ubuntuforums.org/showthread.php?t=1612843, which specify adding the (unique) device ID—available from the output of 'lsinput' from package input-utils—to /var/lib/bluetooth/<physical_ID>/pincodes. This appears to be working so far, with the pairing persisting between logins/reboots.

Revision history for this message
Robert Bruce Park (robru) wrote :

I'm also experiencing this, bluez and hidd both fail to connect ("pairing failed" / "connection refused") but blueman-manager sets up the pairing perfectly on first try. Dunno why bluez can't handle it.

Revision history for this message
Fabián Rodríguez (magicfab) wrote :

I don't work for Canonical anymore nor do I have access to this hardware or interest in it anymore.

It seems the wikipage mentioned in the original bug report above has been updated quite a bit until June last year, and the original report was for Ubuntu 10.10.

I'd suggest makeing sure you are using either Ubuntu 12.04 LTS or the latest Ubuntu version and reviewing the wiki page.

Please open a new bug if this is still a problem, takeing care to specify what Ubuntu version you're using.

Revision history for this message
nh2 (nh2) wrote :

The bluetooth pairing assistant is just terribly broken. It simply doesn't care if you select '0000' or whatever, it will always try its 6-digit pin.

This is what works for me with paring with my Magic Trackpad:

1) Try to pair with the "0000" pin option. It will fail with the 6-digit number. Restart the assistant.
2) Try to pair with the "automatic" pin option. It will fail with the 6-digit number. Restart the assistant.
3) Try to pair with the "0000" pin option again. This time, it will magically work.

This 3-step procedure works for me on Ubuntu 12.04 and 13.04.

Please tell me if it works for you.

Revision history for this message
Fletcher Johnson (flt-johnson) wrote :

Indeed the pairing assistant is broken. It is always trying to use an automatic 6 digit pin. nh2, the method you have proposed does not work for me.

Using:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 12.04.2 LTS
Release: 12.04
Codename: precise

Revision history for this message
Vladimir Dobriakov (vladimir-geekq) wrote :

The pairing assistant in Ubuntu 12.04.2 LTS is still broken.

Only "magical pairing" invented by @nh2 works.

Revision history for this message
Paul M Edwards (paul-m-edwards) wrote :

I've noticed that the pairing assistant wizard remembers the PIN option specified when run as root.
I read on the GNOME blog that GNOME 3.10 will have completely re-done Bluetooth wizard, so this issue (which I'm also experiencing) may be resolved then. I've installed `blueman` in the interim which is an alternative GTK+ bluetooth management utility for GNOME using the bluez D-Bus backend.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

This is reported against an old version of Ubuntu and many things has changed since then. Because of that we won't fix this issue however if this behavior repeats on a modern version please fill a bug report against it and we will take it from there.

Changed in bluez (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Stephan (stephan-stephanx) wrote :

If you read the date on the ticket, it was reported against the current version of Ubuntu at the time. Sure, "Many things change." That doesn't mean the bug was invalid, it just means you "won't fix."

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers