[bluetooth] Connecting to Apple BT keyboard fails due to PIN prompt

[Tony Espy]

Connecting to the latest generation Apple BT keyboard ( the one with the USB port & no batteries ) fails on an Ubuntu Touch device, as when you press the "Connect" button on the device page, a dialog titled "Bluetooth Pairing Request" is displayed, with the following text:

Please confirm that the PIN displayed on 'Magic Keyboard' matches this one: XXXXXX

The dialog has "Cancel" and "Confirm PIN" buttons.

The keyboard has no display on which a PIN could be displayed.

When using other devices ( Ubuntu Desktop 15.10, 16.04, Android, OS X, ... ) to connect this keyboard all that's necessary is to click/press the 'Connect' button in the appropriate place, and the keyboard automatically connects, and is usable with no other actions required from the user.

Reproduced on krillin ( rc-proposed/bq-aquris.en/270 ) which has bluez 5.36-0ubuntu2~overlay1 installed.

Reproduced on arale ( rc-proposed/meizu.en/258 ) which has bluez 5.37 installed from silo 39.

Note, after dismissing the dialog, subsequent attempts to connect may not re-display the PIN dialog, instead nothing happens. I've found that this requires power cycling the keyboard to clear and cause the PIN dialog to be displayed again.

[bluetooth]# show
Controller B8:64:91:48:2B:1E
  Name: Aquaris E4.5 Ubuntu Edition
  Alias: Aquaris E4.5 Ubuntu Edition
  Class: 0x1c020c
  Powered: yes
  Discoverable: no
  Pairable: yes
  UUID: Headset AG (00001112-0000-1000-8000-00805f9b34fb)
  UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
  UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
  UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
  UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
  UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
  UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb)
  UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb)
  UUID: Message Notification Se.. (00001133-0000-1000-8000-00805f9b34fb)
  UUID: Phonebook Access Server (0000112f-0000-1000-8000-00805f9b34fb)
  Modalias: usb:v1D6Bp0246d0525
  Discovering: no

[bluetooth]# devices
Device 18:EE:69:21:6C:D3 18-EE-69-21-6C-D3
Device DE:76:E2:04:9D:6F BB-9D6F
Device 7C:D1:C3:1C:B4:03 7C-D1-C3-1C-B4-03
Device 7C:D1:C3:19:2B:D8 7C-D1-C3-19-2B-D8
Device 84:38:35:67:0C:3D ubuntu-0
Device 04:69:F8:C2:A0:09 tony espy’s Keyboard
Device 00:21:3C:A0:14:A6 Jawbone ERA
Device 1C:1A:C0:B2:9A:D7 1C-1A-C0-B2-9A-D7

Device info *before* pairing attempt:

Device 04:69:F8:C2:A0:09
  Name: tony espy’s Keyboard
  Alias: tony espy’s Keyboard
  Class: 0x002540
  Icon: input-keyboard
  Paired: no
  Trusted: no
  Blocked: no
  Connected: no
  LegacyPairing: no
  Modalias: bluetooth:v004Cp0267d0066

No changes in any of the attributes after *after* the pairing attempt ( output of info command is the same ).

[Simon Fels (morphis)]

This is not necessarily a settings app failure. Can you follow https://wiki.ubuntu.com/DebuggingBluetooth and attach the necessary log files here so that we know what is going on?

[Tony Espy (awe)]

Re-tested on krillin ( rc-proposed/bq-aquaris.en / 270 ), this time with bluez 5.37 installed from the silo.

@Simon, how could this not be a system settings app failure? As I pointed out in my description, pairing this keyboard works fine with every other device I tried, including two Ubuntu desktop systems.

[Simon Fels (morphis)]

Because what pairing method is selected is chosen further down the stack so settings only reacts on what bluez tells it should do. I suspect the keyboard uses pairing capability KeyboardOnly which then should lead to passkey entry where the initiator displays and the responder inputs the PIN (we use KeyboardDisplay) [see Core spec 4.0 page 1968].

However the described dialog on your side is incorrect as it just asks the user to confirm or cancel which could still be an settings app issue just displaying the dialog but also an issue down the stack.

[Simon Fels (morphis)]

And there we go:

Mar 7 15:08:44 ubuntu-phablet bluetoothd[890]: src/device.c:new_auth() Requesting agent authentication for 04:69:F8:C2:A0:09
Mar 7 15:08:44 ubuntu-phablet bluetoothd[890]: src/agent.c:agent_ref() 0xb8c78950: ref=3
Mar 7 15:08:44 ubuntu-phablet bluetoothd[890]: src/agent.c:agent_request_confirmation() Calling Agent.RequestConfirmation: name=:1.119, path=/com/canonical/SettingsBluetoothAgent/adapteragent, passkey=800772

I expected bluez to call DisplayPasskey here rather than RequestConfirmation. So what settings displays is correct (in terms of what it was asked for).

[Simon Fels (morphis)]

Just as a additional note: The actual pairing method is selected in the kernel. See https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bluetooth/smp.c#n859

[Simon Fels (morphis)]

@Tony: Can you reproduce this once again and record the HCI packets by running

 $ sudo btmon -w test.cap

Then attach test.cap here.

[Tony Espy (awe)]

@Simon

Re: comment #6, when I paired the keyboard with my Ubuntu laptops, neither prompted me at all; the keyboard silently paired and was usable.

That said, I'll re-test this afternoon and get you the HCI dump from the phone.

[Tony Espy (awe)]

OK, so I guess I was wrong about pairing working with my Ubuntu desktops ( both running 5.37 ), although I'm pretty sure this worked for me before. Maybe I was running bluez 5.36 when I tested?

Here's a btmon trace of wily running bluez 5.37 on a mid '13 macair. I get prompted to view the PIN just like on krillin.

[Tony Espy (awe)]

And here's the trace for my xenial desktop running on a Thinkpad 410s.

[Tony Espy (awe)]

Note, I forgot to mention in the previous comment that on xenial desktop, the PIN wasn't displayed in settings.

Finally, here's the trace from my krillin, running rc-proposed/bq-aquaris.en #270 + bluez 5.37. Same result as the original bug description.

[Launchpad Janitor (janitor)]

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

[Daniel van Vugt (vanvugt)]

Ubuntu Touch is no longer supported.