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. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1822633 Title: Pairing failure with BLE 4.0 Status in bluez package in Ubuntu: New Status in linux package in Ubuntu: Confirmed Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1822633/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
