Canonical System Image

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

Bug #1551858 reported by Tony Espy
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Canonical System Image
Confirmed
Undecided
Unassigned
bluez (Ubuntu)
Won't Fix
Undecided
Unassigned
ubuntu-system-settings (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

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 ).

See original description
Tony Espy (awe)
tags: added: bluetooth
Revision history for this message
Simon Fels (morphis) wrote :

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?

Simon Fels (morphis)
tags: added: bluez-touch
Revision history for this message
Tony Espy (awe) wrote :
description: updated
Revision history for this message
Tony Espy (awe) wrote :
Revision history for this message
Tony Espy (awe) wrote :
Revision history for this message
Tony Espy (awe) wrote :

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.

Revision history for this message
Simon Fels (morphis) wrote :

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.

Revision history for this message
Simon Fels (morphis) wrote :

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).

Revision history for this message
Simon Fels (morphis) wrote :

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

Revision history for this message
Simon Fels (morphis) wrote :

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

 $ sudo btmon -w test.cap

Then attach test.cap here.

Revision history for this message
Tony Espy (awe) wrote :

@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.

Pat McGowan (pat-mcgowan)
Changed in canonical-devices-system-image:
assignee: nobody → John McAleely (john.mcaleely)
status: New → Confirmed
Revision history for this message
Tony Espy (awe) wrote :

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.

Revision history for this message
Tony Espy (awe) wrote :

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

Revision history for this message
Tony Espy (awe) wrote :

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.

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
Changed in ubuntu-system-settings (Ubuntu):
status: New → Confirmed
John McAleely (john.mcaleely)
Changed in canonical-devices-system-image:
assignee: John McAleely (john.mcaleely) → nobody
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Ubuntu Touch is no longer supported.

Changed in bluez (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.