Qualcomm Atheros QCA6174 [168c:003e] Subsystem [1a56:1535] Pairing failure with BLE 4.0

[You Ren]

When attempting to pair a BLE 4.0 pen using Bluez, we receive authentication errors.

Here is the FW from Jason.

Details:

=======================

I added a few debug statements (patch attached) to the kernel's net/bluetooth/smp.c:smp_sig_channel() function (https://github.com/torvalds/linux/blob/v5.0/net/bluetooth/smp.c#L2883). When I try to pair the PN579X, I get the following logs:

[ 5653.563048] DBG: Received code 2 (allowed = 00000024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 00000028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 00000030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 00000060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 000000a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 00000120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 00000220) with 7 bytes
[ 5654.246182] DBG: Processing code...
[ 5657.610656] input: Dell Active Pen PN579X Keyboard as /devices/virtual/misc/uhid/0005:413C:81D5.0004/input/input23
[ 5657.610997] hid-generic 0005:413C:81D5.0004: input,hidraw0: BLUETOOTH HID vf.08 Keyboard [Dell Active Pen PN579X] on 18:56:80:18:6A:E5

When I try to pair the PN557W, however, I only get the following:

[ 64.924901] DBG: Received code 11 (allowed = 00000024) with 1 bytes
[ 64.924906] DBG: AuthReq = 00
[ 64.924907] ERR: Code not allowed on existing connection
[ 64.924943] Bluetooth: hci0: unexpected SMP command 0x0b from bc:82:5d:fa:5e:b7
[ 64.940314] NET: Registered protocol family 38
[ 65.022326] DBG: Received code 5 (allowed = 00000024) with 1 bytes
[ 65.022331] DBG: Processing code...

The "allowed" value is a bitmap, so 00000024 means that only event code 2 and 5 are allowed. The "smp_sig_channel()" function does allow code 11 ("SMP_CMD_SECURITY_REQ") to be sent from the device at the beginning of the connection but *only* if the "smp" variable hasn't been set yet. It looks like the host starts the pairing process and initializes the "smp" variable, which then prevents code 11 from being allowed.

I did try to force the code to allow code 11 at any time, but this didn't seem to help the situation any. The device still sent code 5 ("SMP_CMD_PAIRING_FAIL") immediately afterwards, just like it does in the trace above. Worse, the kernel logs a general protection fault several seconds afterwards, so it clearly doesn't like the workaround.

I also find it odd that the "AuthReq = 00". I found a copy of the core Bluetooth spec at https://www.bluetooth.com/specifications/bluetooth-core-specification and Vol. 3 Part H Chapter 3.6.7 describes the AuthReq flags. All zero would seem to indicate that no security is requested, and I'm not sure if the kernel enforces a minimum security level or something.

Finally, I also tried the suggestion at https://www.raymondjdouglas.com/blog/2019/airpods-on-arch/ on the assumption that maybe this is an issue caused by LE communication rather than classic BR/EDR communication. Alas, my computer wasn't even able to start the pairing process after making the change.
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 18.04
InstallationDate: Installed on 2019-01-21 (70 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
InterestingModules: bnep btusb bluetooth
MachineType: Dell Inc. XPS 13 9360
Package: linux
PackageArchitecture: amd64
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-46-generic root=UUID=c045330d-1b98-41ff-99cb-26bf69b59fd3 ro quiet splash vt.handoff=1
ProcVersionSignature: Ubuntu 4.15.0-46.49-generic 4.15.18
Tags: third-party-packages bionic
Uname: Linux 4.15.0-46-generic x86_64
UnreportableReason: This is not an official Ubuntu package. Please remove any third party package and try again.
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 05/24/2017
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 2.0.7
dmi.board.name: 0163G1
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvr2.0.7:bd05/24/2017:svnDellInc.:pnXPS139360:pvr:rvnDellInc.:rn0163G1:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.family: XPS
dmi.product.name: XPS 13 9360
dmi.sys.vendor: Dell Inc.
hciconfig:
 hci0: Type: Primary Bus: USB
  BD Address: 9C:B6:D0:E1:81:CE ACL MTU: 1024:8 SCO MTU: 50:8
  UP RUNNING
  RX bytes:708 acl:0 sco:0 events:48 errors:0
  TX bytes:2175 acl:0 sco:0 commands:48 errors:0

[Launchpad Janitor (janitor)]

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

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1822633

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[You Ren (renluluchen)]

apport information

[Daniel van Vugt (vanvugt)]

The first thing I would try is to wait for a fix for bug 1822533 in case that helps.

[Jason Gerecke (killertofu)]

I've just built and installed the master branch of gnome-bluetooth (commit b4edf6a8) and didn't see any behavioral change. Since it isn't even possible to pair through bluetoothctl, I wasn't particularly hopeful that an update to gnome-bluetooth would fix things.

[Jason Gerecke (killertofu)]

I've recently found that while pairing with this pen does not work, "merely" connecting to the pen does work. That is:

# This command fails
$ echo -e "scan on\npair <MAC>\nscan off" | bluetoothctl

# But this command works
$ echo -e "scan on\nconnect <MAC>\nscan off" | bluetoothctl

Looking through the hcidump logs, it appears that "connect" has lower (really, "no") security requirements, which could explain why it succeeds where pairing fails (the AuthReq = 00 sent from the device implies it doesn't want/support security).

I see that GNOME ships /usr/share/gnome-bluetooth/pin-code-database.xml which defines default PINs. Inside the file, it says "the special NULL pin means that the devices will not be paired, but connected to and marked as trusted. This is for devices such as mice and joypads where there is no encryption." If I add the pen to the database by adding the following lines at the top of the "device" section, GNOME pairing starts working (although it seems to be a little hit-or-miss):

<!-- Dell Stylus -->
<device oui="BC:82:5D:" name="Dell PN557W Pen" pin="NULL"/>

====================

With the connection fix in place, a new issue has been identified. Specifically, the kernel input device is removed after processing just a single Bluetooth HID event. Looking at the output of "journalctl -b0", I see the following error message logged, followed by normal device disconnect messages:

bluetoothd[6318]: Error Reading PNP_ID value: Request attribute has encountered an unlikely error

Looking at the hcidump logs, it seems that when the pen's Bluetooth button is pressed, it briefly wakes up only long enough to send a HID report to the system. After doing so, it disconnects to save power. The logs show that the system begins requesting information from the device when it connects, and that it gets a response to some of those requests, but at some point (e.g. when asking for PNP_ID) the device goes to sleep and a response is never returned.

It would seem that there either the system needs to not re-ask the device for information like PNP-ID (which it already received in the initial "connect" process and should have associated with its MAC) or to not be so stringent when these requests fail.

[Kai-Heng Feng (kaihengfeng)]

I think this issue worths raising to to bluetooth mailing list.

[Launchpad Janitor (janitor)]

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