Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#66133 - [bluez] "input-hog profile accept failed" from bluettothd prevents BLE device use.

Attached to Project: Arch Linux
Opened by Lutz Vieweg (lvml) - Sunday, 05 April 2020, 15:02 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Andreas Radke (AndyRTR)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 3
Private No

Details

Description:

After upgrading from bluez-5.53-1-x86_64 to bluez-5.54-1-x86_64.pkg my "Bluetooth Low Energy" mouse (Model: Rapoo M500) is not usable as an input device anymore. When the mouse is switched on, the following message is emitted to the system journal:

Apr 05 00:41:32 hostname bluetoothd[655]: input-hog profile accept failed for ED:8E:0E:XX:XX:XX

(last three bytes replaced by XX by me)

After
pacman -U /var/cache/pacman/pkg/bluez-5.53-1-x86_64.pkg.tar.zst \
/var/cache/pacman/pkg/bluez-libs-5.53-1-x86_64.pkg.tar.zst \
/var/cache/pacman/pkg/bluez-utils-5.53-1-x86_64.pkg.tar.zst
systemctl restart bluetooth
the mouse immediately works again, and vice versa.

I assume this to be a consequence of this commit:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=8cdbd3b09f29da29374e2f83369df24228da0ad1
since this Rapoo Mouse is not "paired" and cannot be "paired" in BLE Mode.

But from what I read, it seems that the options "ClassicBondedOnly" and "LEAutoSecurity" in
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/input.conf
were meant to deal with compatibility to non-pairable BLE devices.

Thus I tried both options, with either "false" or "true" settings, but alas, that makes no difference, the symptom stays the same.
And while the system journal does indicate that bluez-5.54-1-x86_64.pkg has found the "ClassicBondedOnly" option in input.conf -

Apr 05 00:28:07 hostname bluetoothd[20516]: profiles/input/manager.c:input_init() input.conf: ClassicBondedOnly=false

- there is no indication that the "LEAutoSecurity" option was recognized, as if the code of bluez-5.54-1-x86_64.pkg did not know about it.

Additional info:
* package version(s)

bluez-5.54-1-x86_64.pkg - worked fine with previous versions

Steps to reproduce:

Just enabling the mouse shows the symptom.


This task depends upon

Comment by Andreas Radke (AndyRTR) - Sunday, 05 April 2020, 16:01 GMT
Please check for upstream bug reports and maybe ask at some IRC channel: http://www.bluez.org/contact/
Comment by Lutz Vieweg (lvml) - Monday, 13 April 2020, 21:40 GMT
There would not be a reason to check for an upstream bug report, because the current git head at https://git.kernel.org/pub/scm/bluetooth/bluez.git works just fine - I compiled it and tested it. It is only the bluez-5.54-1-x86_64.pkg contained version of bluetoothd that causes the symptom.

The git head version works fine for my mouse with the compiled-in default values of options "ClassicBondedOnly" and "LEAutoSecurity", it also works fine if I use

[General]
ClassicBondedOnly = true
LEAutoSecurity = true

in /etc/bluetooth/input.conf - only if I use ClassicBondedOnly = true and LEAutoSecurity = false with the current git-head version, then my mouse also causes the above mentioned "input-hog profile accept failed for ..." errors.
Comment by Andreas Radke (AndyRTR) - Wednesday, 15 April 2020, 05:49 GMT
Please try if adding this single commit on top of 5.54 also fixes the issue. I can't find any other related commit in master after the release.
Comment by Lutz Vieweg (lvml) - Wednesday, 15 April 2020, 09:12 GMT
"this single commit" meaning which one?
Comment by Lutz Vieweg (lvml) - Wednesday, 15 April 2020, 09:28 GMT
BTW:
zstd -d -c /tmp/bluez-5.54-1-x86_64.pkg.tar.zst | tar xOf - "usr/lib/bluetooth/bluetoothd" | strings -a | grep LEAutoSecurity
displays no match.

But
zstd -d -c /tmp/bluez-5.54-1-x86_64.pkg.tar.zst | tar xOf - "usr/lib/bluetooth/bluetoothd" | strings -a | grep ClassicBondedOnly
does display a match - and that tells me commit
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=f2778f5877d20696d68a452b26e4accb91bfb19e
contributing among others code line
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/manager.c?id=f2778f5877d20696d68a452b26e4accb91bfb19e#n131
is not part of bluez-5.54-1-x86_64.pkg.tar.zst - which explains why the option is not supported by bluez-5.54-1-x86_64.pkg.tar.zst.
Comment by Andreas Radke (AndyRTR) - Wednesday, 15 April 2020, 09:33 GMT
Sorry, I wanted to that commit you to try: https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=35d8d895cd0b724e58129374beb0bb4a2edf9519
Maybe your additional commit is required.

But it's probably better to wait for another release and not worth picking random commits.
Comment by Lutz Vieweg (lvml) - Saturday, 09 May 2020, 22:49 GMT
The Arch package update from bluez 5.54-1 to bluez 5.54-2 at 2020-04-25 did not fix this issue.

bluez-5.54-2-x86_64.pkg.tar.zst also does still not contain the LEAutoSecurity input.conf option.

The current git master branch head from upstream still works fine.
Comment by Andreas Radke (AndyRTR) - Monday, 11 May 2020, 05:20 GMT
Still waiting for a new upstream release or a more hints of required backports. I guess you should keep running your custom git master branch for now.

Loading...