My bluetooth mouse (Lenovo N700) was working fine up till and including 4.1.5. In 4.1.6 an additional check (I suspect [1]) was added. This error message "Bluetooth: SMP security requested but not available" now appears whenever I connect my bluetooth mouse, and repeats every 3 minutes or so. Connection itself is successful as reported by bluedevil. I'm on Arch Linux 64-bit. I have not bisected due to the machine in question being needed for other duties at the moment. [1] - https://lkml.org/lkml/2015/8/14/369
Created attachment 186691 [details] Proposed patch -- UNTESTED Looks like this message was added in 4.1.6. Attached untested patch.
I've tried testing the patch in above attachment 186691 [details] (using the 4.2 kernel, an ASUS T100, and a Logitech MX Anywhere 2 mouse) and unfortunately it produces the same "Bluetooth: SMP security requested but not available" error. As an experiment I tried reverting the original Aug. 15 patch which introduced the check for chan == 0 . With that test removed I get an immediate, complete lock-up of the machine when I try to connect to the mouse, presumably when l2cap_chan_lock is called with the null value. So it appears that check is needed, and it must be some earlier kernel change which first broke access to the mouse. I can't narrow down the origin of the problem better than your report that kernel 4.1.6 version worked, but I did test the T100 with an old 3.16.0 kernel and the mouse did work with it, so this isn't a hardware problem. I've done less extensive tests on a different (ASUS G750) machine and the mouse works with kernel 4.0-rc6 but fails with 4.2. Unfortunately my system isn't set up to easily bisect where the problem actually began.
I just wanted to correct the typo in my own message above to avoid confusion. I incorrectly quoted an earlier message by saying 4.1.6 worked -- the early message actually said 4.1.5 worked (and 4.1.6 didnt).
Further testing reveals that the situation is more complicated than I described above, because it depends upon the past pairing history with the mouse. What I described above is correct if I remove the pairing with the device, then try to redo the pairing from scratch with the above patched kernels. However I get different results if a leave a previous "legacy" pairing in place. I've discovered that I can boot an "old enough" kernel (3.16.0 and probably 4.0-rc6) and successfully pair with and use the mouse. If I then reboot into a 4.2 kernel using either the above attachment 186691 [details] patch or one where I simply revert the Aug. 14 (and it was Aug. 14, not 15) patch, then I do NOT get the SMP warning and the mouse works correctly. If I boot the 4.2 kernel WITH the Aug. 14 patch, I DO get the SMP warning and the mouse fails. So it looks like there are two different but related problems. The practical effect of the Aug. 14 patch is to forbid "legacy" pairings and the 186691 attachment removes that legacy prohibition in a crash-proof way. Unfortunately there is some additional but perhaps related bug which prevents the 4.2 kernel and either modified version from successfully creating a new "correct" pairing with the mouse. When, under 4.2 with or without the 186691 patch, I remove any legacy pairing then use bluetoothctl to try to establish a new pairing, the "pair command SAYS it completes successfully, but it triggers the SMP error message viewable with with dmesg. Although later "connect" commands sometimes SAY they succeed (they are not consistent), the mouse is never usable. As mentioned earlier, if I try to create a new pairing after removing the Aug. 14 patch entirely, then the system locks up immediately. At this point I've probably reached the limits of my understanding of the bluetooth system, but if others have patches, I'd be happy to test them.
Could you check if toggling power from bluetoothctl (power off/ power on) fix not being able to pair on 4.2 ? If so then adapter was powered in legacy way (eg hciconfig up) where SMP is not correctly initialized.
I did just test using the bluetoothctl power off / power on sequence. After doing that, pairing DOES in fact work properly with a stock (as far as bluetooth is concerned) 4.2 kernel. The mouse then works well until I reboot. I've tested this both on an ASUS T100 and also on an ASUS G750. I'll need to do more investigating to understand why the adapter was powered on in legacy mode and how I can change that. If you have any suggestions I'd appreciate those. I do run into the following complications after a reboot. The g750 ones are "minor" but may indicate some further patches are needed. The T100 ones are more serious, but those are presumably because I'm currently "manually" using "hciconf hci0 up", which you say will cause problems. The following may be more than you need to know, but in case it is useful, here's more detail on the two machines and their different behavior: On the G750, once I establish a good pairing then reboot, I do NOT need to repeat the bluetoothctl power off / power on sequence again. The bluetooth mouse connection just succeeds automatically after the reboot. However dmesg DOES show that the "SMP security requested but not available" message has been output. After a reboot on the T100 the mouse does NOT work. The bluetoothctl info command claims it is connected, but the mouse does not appear in the xinput device list. Powering the controller off then on then trying to reconnect does not seem to help. I need to start from scratch by removing the pairing then redoing that pairing. On both machines I'm running openSUSE 13.2 KDE with bluez 5.23-1.1 (from the openSUSE distribution) and bluedevil 2.1.1-2.5.1 from openSUSE update. Even before the recent issue with the MX Anywhere 2, getting ANY bluetooth to run on the G750 was a bit of a struggle, mostly involving extracting and installing BCM20702A1 firmware. There were a number of false steps getting to that point so I could have mangled the configuration somehow. Getting bluetooth running on the T100 was even more complicated as it is a relatively new Baytrail tablet with lots of gaps in linux hardware support. Following advice on various forums, I first use brcm_patchram_plus to load an hcd file and set the MAC address. I then use hciattach to connect the bluetooth software to the bcm chip through the Baytrail /dev/ttyS4 port. Finally, I use hciconfig hci0 up to bring up the bluetooth interface. If there is a new alternative to the last one or two commands which will properly initialize SMP, could you let me know? Thanks for the advice. Let me know if there are further tests which would be useful.
I'm only now re-updating the kernel and so looking back into this. power off and on in bluetoothctl does not fix this for me (linux-4.2). I have not applied any patches due to a lack of spare time at the moment, though.
I have a Microsoft Designer BT Mouse, and was also experiencing these issues, upon upgrading to 4.1.6 . After finding that the card was being brought up in 'legacy' mode, I was able to upgrade to 4.2 and bring it up using bluetoothctl to get the mouse to pair and connect successfully, however rebooting breaks it. Arch Linux 64bit is installed using the testing branch. The culprit for 'legacy' mode was a udev rule suggested on the ArchWiki, which used hciconfig to bring the interface up.
Even after removing that legacy rule I can't get my bluetooth mouse to reliably connect and stay connected. Sometimes it connects (on a first pair) and then will not reconnect after it goes to sleep. Same error message, but an additional line which may or may not be useful:- Bluetooth: hci0 unexpected SMP command 0x0b from de:e3:d3:d7:de:32
Still an issue as of 4.5.1. I've been using this mouse with its dongle for months now, and decided to revisit this issue now that my semester is coming to an end. No movement so far, can I help provide any other information?
(In reply to ngoonee.talk from comment #10) > Still an issue as of 4.5.1. I've been using this mouse with its dongle for > months now, and decided to revisit this issue now that my semester is coming > to an end. No movement so far, can I help provide any other information? Are you sure that CONFIG_UHID is enabled in your kernel config? After asking for help on irc, I got a tip to enable that module, and it was that module that was missing for me.
zcat /proc/config.gz | grep UHID CONFIG_UHID=m Currently on 4.6.5 it is able to connect (seems better than the first time), but after a reboot it remains paired but does not reconnect. bluetoothd gives the error 'sap-server: Operation not permitted (1)' Running bluetoothctl and trying to run a 'connect' to the paired device gives these errors for bluetoothd 'ATT bt_io_connect(<address here>): connect: No route to host (113)' Unpairing and repairing the mouse makes it work, but bluetoothd gives these errors:- 'bt_uhid_send: Invalid argument (22)'
I am running a fresh build of Mint 18, modified for real-time by: sudo apt-get install linux-lowlatency linux-headers-lowlatency Linux 4.4.0-34-lowlatency #53-Ubuntu SMP PREEMPT Wed Jul 27 19:23:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux I am typing this on a Dell XPS 15, with a Broadcom BCM20703A bluetooth chip. that is now persistently paired / connected to a "Arc Touch Mouse SE". two issues were encountered while getting this bluetooth mouse to work. 2. the "Bluetooth: SMP security requested but not available" error message that is encountered via ">> dmesg | tail" during BT mouse pairing (required only once) due to an apparently incorrect.. [powered in legacy way (eg hciconfig up) where SMP is not correctly initialized. see comment #5 above] was worked around by "sudo bluetoothctl -a" power off/on toggling... so it seems Szymon Janc's hunch is on the right track.. but it also seems likely that successful blue-tooth device pairing likely requires running bluetoothctl with some level of elevated privilege, if one wishes this bluetooth pairing to remain persistent across reboots. having done this once paired, my Arc Touch Mouse SE seems to come up working after a reboot.. 1. But before the above SMP security bug workaround might work.. if one's bluetooth controller happens to be a Broadcom device.. in my case the BCM20703A found in a more recent Dell XPS 15. you may find this error message in the logs: >> dmesg | egrep 'blue|firm' [ 4.220629] brcmfmac 0000:02:00.0: Direct firmware load for brcm/brcmfmac43602-pcie.txt failed with error -2 if so, you will also likely want to place this file: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1589889/+attachment/4683974/+files/BCM-0a5c-6410.hcd into the /lib/firmware/bcrm/ directory.. for details see: http://osdir.com/ml/ubuntu-bluetooth/2016-06/msg00043.html That said, my really cool Arc Touch Mouse bluetooth mouse seems quite happily persistently paired to new dell XPS 15.. thanks for the clue regarding the need to work around the power mode during blue-tooth device pairing..! hope this helps resolve the last remaining blue-tooth driver issues for Linux..