[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
** Tags added: hwe-networking-wifi
** Tags removed: hwe-networking-wifi
** Tags added: hwe-bluetooth
--
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:
Confirmed
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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=
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.
[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: bluez (Ubuntu)
Status: New => Confirmed
--
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:
Confirmed
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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=
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
[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
I think this issue worths raising to to bluetooth mailing list.
--
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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=
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
[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
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 \nscan off" | bluetoothctl
# But this command works
$ echo -e "scan on\nconnect \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):
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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
[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
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.
--
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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=
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
[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
The first thing I would try is to wait for a fix for bug 1822533 in case
that helps.
--
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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=
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
[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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=
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
[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
apport information
** Tags added: apport-collected bionic third-party-packages
** Description changed:
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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.
+ 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=
+ 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:
[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
** Project changed: snappy-hwe-snaps => linux (Ubuntu)
--
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:
Incomplete
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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.
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
[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux (Ubuntu)
Status: New => Confirmed
--
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:
Incomplete
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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.
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
[Kernel-packages] [Bug 1822633] Re: Pairing failure with BLE 4.0
** Also affects: bluez (Ubuntu)
Importance: Undecided
Status: New
--
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:
Incomplete
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 = 0024) with 6 bytes
[ 5653.563053] DBG: Processing code...
[ 5653.709572] DBG: Received code 3 (allowed = 0028) with 16 bytes
[ 5653.709577] DBG: Processing code...
[ 5653.807085] DBG: Received code 4 (allowed = 0030) with 16 bytes
[ 5653.807089] DBG: Processing code...
[ 5654.148553] DBG: Received code 6 (allowed = 0060) with 16 bytes
[ 5654.148557] DBG: Processing code...
[ 5654.197024] DBG: Received code 7 (allowed = 00a0) with 10 bytes
[ 5654.197027] DBG: Processing code...
[ 5654.245824] DBG: Received code 8 (allowed = 0120) with 16 bytes
[ 5654.245828] DBG: Processing code...
[ 5654.246178] DBG: Received code 9 (allowed = 0220) 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 = 0024) 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 = 0024) with 1 bytes
[ 65.022331] DBG: Processing code...
The "allowed" value is a bitmap, so 0024 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.
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
