The patch, included in kernel 3.14.6 (upstream commit 09da1f3463eb81d59685df723b1c5950b7570340), breaks normal operation for bluetooth keyboards. Defect occurred with Microsoft Bluetooth Mobile Keyboard 6000, but could affect wider range of device. The bluetooth re-auth is not supported and the device disconnects continuously making impossible to input. Could be useful an encrypt pending set after unsuccessful re-auth? From syslog: Jun 9 08:29:34 supermicro-0 kernel: [ 54.330234] Bluetooth: re-auth of legacy device is not possible. Jun 9 08:29:34 supermicro-0 kernel: [ 54.330955] hid-generic 0005:045E:0762.0005: unknown main item tag 0x0 Jun 9 08:29:34 supermicro-0 kernel: [ 54.331097] input: Microsoft Bluetooth Mobile Keyboard 6000 as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.5/2-1.5:1.0/bluetooth/hci0/hci0:2/0005:045E:0762.0005/input/input8 Jun 9 08:29:34 supermicro-0 kernel: [ 54.331317] hid-generic 0005:045E:0762.0005: input,hidraw4: BLUETOOTH HID v0.13 Keyboard [Microsoft Bluetooth Mobile Keyboard 6000] on 00:15:83:0c:bf:eb
Could you please provide an HCI trace of the matter, e.g. with btmon -w <file>. Otherwise it's a bit difficult to debug this. The patch in question was created to pass a GAP Bluetooth qualification test case for SSP. Without it the test case would fail.
where can i find btmon? It's not available on my system... I'm using Ubuntu 14.04
I've got the same Microsoft Bluetooth Mobile Keyboard 6000 and couldn't reproduce the issue with current bluetooth-next tree which contains the same patch. I also tried with an Apple Bluetooth keyboard and didn't observe any issues. Both devices are able to pair and reconnect just fine.
(In reply to Marco Minetti from comment #2) > where can i find btmon? It's not available on my system... I'm using Ubuntu > 14.04 I don't really know about distribution specific packaging, but btmon is part of BlueZ and resides in the monitor/ subdirectory of the source tree. However, if your distribution packages hcidump (the predecessor of btmon) you can also use it to create a similar file (hcidump -w <file>).
Ok for hcidump...
For the record, I tried both with Bluetooth 2.0 and a 4.0 adapters to exclude the chance that this issue is something specific to non-SSP connections, but I still can't reproduce the problem.
(In reply to Marco Minetti from comment #5) > Ok for hcidump... Did you mean to create an attachment? I haven't seen one yet.
Here the attachment... I've just tried to type "m" in login screen (lightdm). After some "m" keypress the keyboard disconnects, then it reconnects.
Created attachment 138591 [details] hcidump.log
Thanks. I just realized that bluetooth-next.git doesn't have this patch yet as it went upstream via bluetooth.git, which is probably why I haven't been able to reproduce it. So this looks like a real thing, however now we need to find a way to fix it without breaking the qualification test case that the original patch was created for.
After cherry-picking the patch to my (bluetooth-next based) tree I can also reproduce this issue. It'll take a while to come up with a proper fix for it though (besides the a brute-force revert which might be necessary for the stable trees for now).
I am experiencing this problem as well, and can confirm it's a regression from 3.14.5 - 3.14.6. I have the same keyboard model Microsoft Bluetooth Mobile Keyboard 6000 and confirm the exactly same behavior. I downgraded to 3.14.5 and the keyboard is back to normal.
Created attachment 138801 [details] Fix proposal The attached patch should fix the issue (at least it does with my Microsoft keyboard). It should be applied on top of the original patch that exposed this bug (e.g. 3.14.6). The "specialty" with this keyboard is that it seems to request authentication but not encryption when it connects. This causes a link key request/response on our side but no encryption change event. The code was incorrectly using the key_type variable (that gets set when we respond to the link key request) to determine whether we're encrypted or not, however with this keyboard this is not a reliable way to do it. Instead, we already track the real encryption state in the link_mode variable, which is what the patch changes the code to use instead of key_type.
Thank you Johan, i applied the patch and it indeed fixes the problem.
I'm compiling kernel 3.15.0 right now... I'll test when it's ready... hopefully your patch will solve the problem for me too! ;)
Fixed! I'm just typing with my Bluetooth keyboard. That's awesome. Thanks Johan! Do I close the bug?
Good to hear that the fix works! The patch has been applied to the Bluetooth subsystem tree and will eventually be sent to the stable trees, so if that's enough then I guess the bug can be resolved as fixed.
Any news about patch merge into stable trees?
The patch seems to have been pulled into Linus' tree last night from the net tree. It has a Cc: stable tag so I'd expect it to follow the usual path into stable trees. For reference, the commit id in Linus's tree is e694788d73efe139b24f78b036deb97fe57fa8cb
I can confirm that patch has been included in kernel 3.15.5. ;) Thanks again Johan!