Bug 1289863 - Bluetooth keyboards no longer work
Bluetooth keyboards no longer work
Status: NEW
Product: Fedora
Classification: Fedora
Component: bluez (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Don Zickus
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-09 03:49 EST by Berend De Schouwer
Modified: 2017-10-06 02:30 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-12-20 11:49:29 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Logs (journalctl) of a bluetooth connection that results in a broken keyboard (3.02 KB, text/plain)
2015-12-13 02:03 EST, Berend De Schouwer
no flags Details
Logs (journalctl) of a bluetooth connection that results in a working keyboard (2.92 KB, text/plain)
2015-12-13 02:04 EST, Berend De Schouwer
no flags Details
btmon log (85.43 KB, text/plain)
2017-03-22 04:22 EDT, Berend De Schouwer
no flags Details
dmesg output (73.65 KB, text/plain)
2017-03-22 04:22 EDT, Berend De Schouwer
no flags Details
usbmon log (76.59 KB, text/plain)
2017-03-22 04:23 EDT, Berend De Schouwer
no flags Details
journalctl for bluetoothd -d (38.12 KB, text/plain)
2017-03-22 04:24 EDT, Berend De Schouwer
no flags Details
btmon log on Kinsgton Bluetooth (85.43 KB, text/plain)
2017-03-28 03:32 EDT, Berend De Schouwer
no flags Details
btmon log on Kinsgton Bluetooth (527.32 KB, text/plain)
2017-03-28 03:34 EDT, Berend De Schouwer
no flags Details
dmesg log for Kingston bluetooth dongle (13.29 KB, text/plain)
2017-03-28 03:35 EDT, Berend De Schouwer
no flags Details
journalctl log for kingston dongle (46.50 KB, text/x-vhdl)
2017-03-28 03:35 EDT, Berend De Schouwer
no flags Details
usbmon log for kingston dongle (360.01 KB, text/plain)
2017-03-28 03:36 EDT, Berend De Schouwer
no flags Details

  None (edit)
Description Berend De Schouwer 2015-12-09 03:49:55 EST
Description of problem:

Bluetooth keyboards no longer work.  They used to work a few weeks ago in Fedora 23.

The keyboards (I've tried 4) still pair, and still connect to gnome-bluetooth, but anything typed does not show up anywhere.  There's no input into gnome-terminal, for example.

At the same time USB keyboards work, and Bluetooth mice work fine.


Version-Release number of selected component (if applicable):

bluez-5.36-1.fc23.x86_64
kernel-4.2.6-300.fc23.x86_64
kernel-4.2.6-301.fc23.x86_64 (also tried rawhide kernel)


How reproducible:

Every time


Steps to Reproduce:
1. pair bluetooth keyboard
2. type connection password (usually six digits; this does work)
3. use bluetooth keyboard


Actual results:

Keyboard pairs.  Keyboard doesn't type.


Expected results:

Keyboard pairs.
Keyboard types.


Additional info:

Tried:
- apple
- logitech
- astrum
- kanex

Definitely used to work.
Comment 1 Berend De Schouwer 2015-12-09 08:42:27 EST
Also tried:

- X11
- Wayland
- Console

No input.


xinput output (whether or not a bluetooth keyboard is paired):

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=14	[slave  pointer  (2)]
⎜   ↳ Logitech Bluetooth Mouse M555b          	id=17	[slave  pointer  (2)]
⎜   ↳ USB keyboard                            	id=11	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ USB keyboard                            	id=10	[slave  keyboard (3)]
    ↳ HP Wireless hotkeys                     	id=15	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ HP WMI hotkeys                          	id=16	[slave  keyboard (3)]
    ↳ Video Bus                               	id=8	[slave  keyboard (3)]
    ↳ HP HD Webcam                            	id=12	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=13	[slave  keyboard (3)]


hcidump for hitting 'a':

> ACL data: handle 9 flags 0x02 dlen 14
    L2CAP(d): cid 0x0041 len 10 [psm 19]
      HIDP: Data: Input report
> ACL data: handle 9 flags 0x02 dlen 14
    L2CAP(d): cid 0x0041 len 10 [psm 19]
      HIDP: Data: Input report

(I assume one is key press, one is key release)
Comment 2 Berend De Schouwer 2015-12-10 03:00:55 EST
It's working right now.

The fix seemed to have been to delete a bunch of stuff in /var/lib/bluetooth/

All the files in there were OK (by cat-ing), but it's possible there were too many (about 25) and there were two macs for two different bluetooth controllers.

The bluetooth keyboards do now appear in xinput.

Next time it happens I'll try and replicate it by keeping a backup and putting the files back into /var/lib/bluetooth/ to verify.
Comment 3 Berend De Schouwer 2015-12-11 00:52:44 EST
This is back.

So it's not data in /var/lib/bluetooth/

I still can't for sure say when it will happen.  Switching bluetooth off and on sometimes helps (but not always).  The bluetooth mice do work when all the keyboards stop.

It looks like HIDP is missing sometimes when the pairing happens.


The following happened during a bad pairing (mouse works; keyboard doesn't)

[   30.441937] hid-generic 0005:046D:B009.0003: unknown main item tag 0x0
[   30.442018] input: Logitech Bluetooth Mouse M555b as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:1/0005:046D:B009.0003/input/input25
[   30.442917] hid-generic 0005:046D:B009.0003: input,hidraw2: BLUETOOTH HID v4.19 Mouse [Logitech Bluetooth Mouse M555b] on c4:8e:8f:c1:99:7a
[   40.044447] Bluetooth: hci0 ACL packet for unknown connection handle 2
[   46.357048] Bluetooth: hci0 ACL packet for unknown connection handle 3
[   62.642990] Adjusting tsc more than 11% (8055346 vs 7777428)


The following happens during a good pair:

[  117.729206] hid-generic 0005:046D:B009.0004: unknown main item tag 0x0
[  117.729292] input: Logitech Bluetooth Mouse M555b as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:1/0005:046D:B009.0004/input/input26
[  117.730739] hid-generic 0005:046D:B009.0004: input,hidraw2: BLUETOOTH HID v4.19 Mouse [Logitech Bluetooth Mouse M555b] on c4:8e:8f:c1:99:7a
[  146.209149] Bluetooth: hci0 ACL packet for unknown connection handle 2
[  159.677777] apple 0005:05AC:0256.0005: unknown main item tag 0x0
[  159.677990] input: Apple Wireless Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:3/0005:05AC:0256.0005/input/input27
[  159.678998] apple 0005:05AC:0256.0005: input,hidraw3: BLUETOOTH HID v0.50 Keyboard [Apple Wireless Keyboard] on c4:8e:8f:c1:99:7a
Comment 4 Berend De Schouwer 2015-12-13 02:00:31 EST
OK, I've been able to trigger it a bit more regularly.

It looks like there's a stale "connected" state that persists.  When un-suspending the laptop sometimes the device works, sometimes it doesn't.

A working wake-up and broken wake-up are attached for an Apple keyboard.  Note how both end in gdm-x-session recording "tagged by udev as: Keyboard".

The broken one starts with:
kernel: Bluetooth: hci0 ACL packet for unknown connection handle 8
and ends with "tagged by udev as: Keyboard".

Note that it ends with the correct udev tag, but no input.

These "unknown connection handle" logs loop with different digits until eventually a working handle # is found; but this can take a long time.

I assume some stale connection handle # is remembered somewhere; but that this # is either in-correct, or the controller and device have a different memory of state.
Comment 5 Berend De Schouwer 2015-12-13 02:03 EST
Created attachment 1105280 [details]
Logs (journalctl) of a bluetooth connection that results in a broken keyboard
Comment 6 Berend De Schouwer 2015-12-13 02:04 EST
Created attachment 1105281 [details]
Logs (journalctl) of a bluetooth connection that results in a working keyboard
Comment 7 Don Zickus 2016-09-19 15:13:53 EDT
Hi,

Does the problem go away after you install the 'bluez-hid2hci' package.  That
package special cases your keyboard.  Install the package and reboot to
have udev pick up the new rule.

Cheers,
Don
Comment 8 Berend De Schouwer 2016-09-20 04:19:19 EDT
I've had that package installed for a long time now, it's still broken.

And it's multiple keyboard manufacturers, not just one.

I think it's related to the built-in Realtek bluetooth device.  It doesn't seem to happen with an external Kensington.  I've been using an external dongle to work around the problem for a while now.  But then why do mice work?
Comment 9 Fedora End Of Life 2016-11-24 09:05:20 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 10 Fedora End Of Life 2016-12-20 11:49:29 EST
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 11 Berend De Schouwer 2016-12-21 02:32:43 EST
Still a problem in F25
Comment 12 gopal krishna tiwari 2017-03-21 02:30:06 EDT
Hi,


I am helping Don here to further diagnose the problem. It would be great if you can share the following debugging logs started in separate console. 

Please share the following once the problem is reproduced and capture in the following logs 

1) btmon output 
2) usbmon output 
3) dmesg out put  
4) journalctl -f --unit=bluetooth output once we have -d option enable (daemon restart is done )

Just one confirmation if their is good pair..  is the keyboard works ever after smoothly or it stops later ?

Gopal...
Comment 13 Berend De Schouwer 2017-03-22 04:22 EDT
Created attachment 1265318 [details]
btmon log
Comment 14 Berend De Schouwer 2017-03-22 04:22 EDT
Created attachment 1265319 [details]
dmesg output
Comment 15 Berend De Schouwer 2017-03-22 04:23 EDT
Created attachment 1265320 [details]
usbmon log
Comment 16 Berend De Schouwer 2017-03-22 04:24 EDT
Created attachment 1265321 [details]
journalctl for bluetoothd -d
Comment 17 Berend De Schouwer 2017-03-22 04:27:52 EDT
I've attached the requested logs.


In this case:
1. use a logitech bluetooth keyboard and logitech bluetooth mouse
2. reboot laptop
3. gnome settings shows keyboard and mouse connected
4. keyboard doesn't react
4a. various buttons were pushed, and logged in btmon.
5. at 10:18:27 disconnect the keyboard in gnome settings
6. reconnect the keyboard in gnome-settings
7. keyboard works

Normally after the bluetooth devices connect and work, they remain working until either the device or the laptop loses power.
Comment 18 Berend De Schouwer 2017-03-22 04:29:53 EDT
Edit: 4b. the mouse was working.

_This_ keyboard has a built-in trackpad too.  Trackpad wasn't working.
Comment 19 gopal krishna tiwari 2017-03-23 04:38:38 EDT
I am still understanding the reports ...Meanwhile can you please check 

This also might be related to autosuspend, so either a 

usbcore.autosuspend=-1 ( A boot argument)

to disable it and reboot, might work.  Or a 

echo 'on' > /sys/bus/usb/devices/<device>/pwoer/control

might resolve it on a per-device basis.

Gopal...
Comment 20 Berend De Schouwer 2017-03-23 04:45:48 EDT
/sys/bus/usb/devices/<device>/power/control was already on (it's also the wireless card)
Comment 21 gopal krishna tiwari 2017-03-23 08:37:23 EDT
My report analysis ...
Still have to dig through  

> HCI Event: Mode Change (0x14) plen 6                         [hci0] 11.915316
        Status: Success (0x00)
        Handle: 2
        Mode: Sniff (0x02)
        Interval: 67.500 msec (0x006c)
= bluetoothd: Can't get HIDP connection info                          16.521632  <<-------------- (1)
@ MGMT Command: Start Discovery (0x0023) plen 1       {0x0001} [hci0] 17.025226
        Address type: 0x07
          BR/EDR
          LE Public
          LE Random
< HCI Command: LE Set Random Address (0x08|0x0005) plen 6      [hci0] 17.025247
        Address: 18:EF:96:0C:0F:27 (Non-Resolvable)
> HCI Event: Command Complete (0x0e) plen 4                    [hci0] 17.026328
      LE Set Random Address (0x08|0x0005) ncmd 2
        Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7     [hci0] 17.026353
        Type: Active (0x01)
        Interval: 11.250 msec (0x0012)
        Window: 11.250 msec (0x0012)
        Own address type: Random (0x01)
        Filter policy: Accept all advertisement (0x00)
> HCI Event: Command Complete (0x0e) plen 4                    [hci0] 17.027324
      LE Set Scan Parameters (0x08|0x000b) ncmd 2
        Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2         [hci0] 17.027345
        Scanning: Enabled (0x01)
        Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4                    [hci0] 17.028324
      LE Set Scan Enable (0x08|0x000c) ncmd 2
        Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 4        {0x0001} [hci0] 17.028348
      Start Discovery (0x0023) plen 1
        Status: Success (0x00)
        Address type: 0x07
          BR/EDR
          LE Public
          LE Random
@ MGMT Event: Discovering (0x0013) plen 2             {0x0002} [hci0] 17.028354
        Address type: 0x07
          BR/EDR
          LE Public
          LE Random
        Discovery: Enabled (0x01)
@ MGMT Event: Discovering (0x0013) plen 2             {0x0001} [hci0] 17.028354
        Address type: 0x07
          BR/EDR
          LE Public
          LE Random
        Discovery: Enabled (0x01)
> HCI Event: LE Meta Event (0x3e) plen 43                      [hci0] 17.646304
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Connectable undirected - ADV_IND (0x00)
        Address type: Random (0x01)
        Address: D5:48:4B:B5:7F:91 (Static)
        Data length: 31
        Flags: 0x04
          BR/EDR Not Supported
        128-bit Service UUIDs (partial): 1 entry
          Vendor specific (adabfb00-6e7d-4601-bda2-bffaa68956ba)
        Service Data (UUID 0x180a): 120453810000
        RSSI: -88 dBm (0xa8)
> ACL Data RX: Handle 2 flags 0x02 dlen 14                     [hci0] 18.595790
      Channel: 65 len 10 [PSM 0 mode 0] {chan 0}
        a1 01 04 00 00 00 00 00 00 00                    ..........      
> HCI Event: Mode Change (0x14) plen 6                         [hci0] 18.664337
        Status: Success (0x00)
        Handle: 2
        Mode: Active (0x00)
        Interval: 0.000 msec (0x0000)
> HCI Event: Mode Change (0x14) plen 6                         [hci0] 18.709336
        Status: Success (0x00)
        Handle: 2
        Mode: Sniff (0x02)
        Interval: 11.250 msec (0x0012)
> ACL Data RX: Handle 2 flags 0x02 dlen 14                     [hci0] 18.719546
      Channel: 65 len 10 [PSM 0 mode 0] {chan 0}
        a1 01 00 00 00 00 00 00 00 00                    ..........      
> ACL Data RX: Handle 2 flags 0x02 dlen 14                     [hci0] 18.820778
      Channel: 65 len 10 [PSM 0 mode 0] {chan 0}
        a1 01 04 00 00 00 00 00 00 00                    ..........      
> ACL Data RX: Handle 2 flags 0x02 dlen 14                     [hci0] 18.955789
      Channel: 65 len 10 [PSM 0 mode 0] {chan 0}
        a1 01 00 00 00 00 00 00 00 00                    ..........      
@ MGMT Command: Disconnect (0x0014) plen 7            {0x0001} [hci0] 19.026473    <<------------------- Disconnect event 
        BR/EDR Address: 00:07:61:75:60:25 (29530)
< HCI Command: Read Clock Offset (0x01|0x001f) plen 2          [hci0] 19.026492
        Handle: 2
> HCI Event: Command Status (0x0f) plen 4                      [hci0] 19.028327
      Read Clock Offset (0x01|0x001f) ncmd 2
        Status: Success (0x00)
< HCI Command: Disconnect (0x01|0x0006) plen 3                 [hci0] 19.028350
        Handle: 2
        Reason: Remote User Terminated Connection (0x13)  <<-------------------------------------  though before I could see some of ACL RX data .. 


Dec 13 08:34:04 sieve-deschouwer-co-za kernel: Bluetooth: hci0 ACL packet for unknown connection handle 8 <<--------------------------- That's where handle is missing later 
Dec 13 08:34:10 sieve-deschouwer-co-za kernel: apple 0005:05AC:0256.000B: unknown main item tag 0x0
Dec 13 08:34:10 sieve-deschouwer-co-za kernel: input: Apple Wireless Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:9/0005:05AC:0256.000B/input/input75
Dec 13 08:34:10 sieve-deschouwer-co-za kernel: apple 0005:05AC:0256.000B: input,hidraw0: BLUETOOTH HID v0.50 Keyboard [Apple Wireless Keyboard] on c4:8e:8f:c1:99:7a
Dec 13 08:34:10 sieve-deschouwer-co-za /usr/libexec/gdm-x-session[3841]: (II) config/udev: Adding input device Apple Wireless Keyboard (/dev/input/event16)
Dec 13 08:34:10 sieve-deschouwer-co-za /usr/libexec/gdm-x-session[3841]: (**) Apple Wireless Keyboard: Applying InputClass "evdev keyboard catchall"
Dec 13 08:34:10 sieve-deschouwer-co-za /usr/libexec/gdm-x-session[3841]: (**) Apple Wireless Keyboard: Applying InputClass "libinput keyboard catchall"
Dec 13 08:34:10 sieve-deschouwer-co-za /usr/libexec/gdm-x-session[3841]: (**) Apple Wireless Keyboard: Applying InputClass "system-keyboard"


Mar 22 10:18:20 sieve-deschouwer-co-za bluetoothd[1122]: src/device.c:connect_profiles() /org/bluez/hci0/dev_00_1F_20_35_A8_34 00001101-0000-1000-8000-00805f9b34fb, client :1.62
Mar 22 10:18:24 sieve-deschouwer-co-za bluetoothd[1122]: src/service.c:change_state() 0x55c9b75c9450: device 00:07:61:75:60:25 profile input-hid state changed: connected -> disconnecting (0)
Mar 22 10:18:24 sieve-deschouwer-co-za bluetoothd[1122]: profiles/input/device.c:input_device_disconnect()
Mar 22 10:18:24 sieve-deschouwer-co-za bluetoothd[1122]: Can't get HIDP connection info   <<----------------------------- (1) 
Mar 22 10:18:24 sieve-deschouwer-co-za bluetoothd[1122]: src/service.c:change_state() 0x55c9b75c9450: device 00:07:61:75:60:25 profile input-hid state changed: disconnecting -> disconnected (0)
Mar 22 10:18:25 sieve-deschouwer-co-za bluetoothd[1122]: src/adapter.c:start_discovery_timeout()
Mar 22 10:18:25 sieve-deschouwer-co-za bluetoothd[1122]: src/adapter.c:start_discovery_timeout() adapter->current_discovery_filter == 0

Which kind of looks like failed while reading the HID info .. 

Could see some of the firmware errors as well 

[   18.516521] bluetooth hci0: Direct firmware load for rtl_bt/rtl8723b_config.bin failed with error -2
[   18.516523] Bluetooth: hci0: Failed to load rtl_bt/rtl8723b_config.bin
[   18.516527] Bluetooth: hci0: rtl: loading rtl_bt/rtl8723b_fw.bin
[   18.518174] Bluetooth: hci0: rom_version status=0 version=1
[   18.518181] Bluetooth: cfg_sz 0, total size 22496
[   18.542033] rtlwifi: loading out-of-tree module taints kernel.
[   18.542087] rtlwifi: module verification failed: signature and/or required key missing - tainting kernel

Not sure is the above is playing role here.. 

Gopal..
Comment 22 Berend De Schouwer 2017-03-23 12:10:00 EDT
rtlwifi is from rtlwifi_new, because the stock kernel driver doesn't work with the wifi card.  I'm happy to load a kernel without the tainted module to upload logs.

There is a rtl8723b_fw.bin in /usr/lib/firmware/, and it's still the one from the stock linux-firmware-20161205 package.  I've verified with rpm -V.  The latest firmware I can find in git is the same version, and from december 2015 (but that doesn't mean it's OK...)

I apologise for the intermixed apple keyboard messages.  I'll try and take the batteries out before I create new logs, and my phone.



I can try and re-connect mouse/keyboard separately with 30 seconds to see if there's just too much data up front.  Maybe the chip just can't deal with two re-connects simultaneously.
Comment 23 Berend De Schouwer 2017-03-28 03:32 EDT
Created attachment 1266850 [details]
btmon log on Kinsgton Bluetooth

btmon log for a different bluetooth dongle on the same keyboard/mouse
Comment 24 Berend De Schouwer 2017-03-28 03:34 EDT
Created attachment 1266851 [details]
btmon log on Kinsgton Bluetooth

Accidentally copied the old btmon.log twice.  This is the real second one
Comment 25 Berend De Schouwer 2017-03-28 03:35 EDT
Created attachment 1266852 [details]
dmesg log for Kingston bluetooth dongle
Comment 26 Berend De Schouwer 2017-03-28 03:35 EDT
Created attachment 1266853 [details]
journalctl log for kingston dongle
Comment 27 Berend De Schouwer 2017-03-28 03:36 EDT
Created attachment 1266854 [details]
usbmon log for kingston dongle
Comment 28 Berend De Schouwer 2017-03-28 03:40:51 EDT
These logs are for a kingston dongle that shows up under lsusb as:
Bus 002 Device 027: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)


This dongle isn't made by Realtek, and doesn't use btrtl or rtlwifi.  It also doesn't use rtl-firmware.

It's harder to trigger the same bug with this dongle, but not impossible.

I had to remove & re-pair the keyboard before it would work.


To remind:
- mouse works of-the-bat
- keyboard (multiple manufacturers) doesn't always pair automatically after suspend

Suspect, not verified:
- it affects the second bluetooth device.  If the keyboard pairs first, the mouse might give problems.
Comment 29 gopal krishna tiwari 2017-04-07 05:13:57 EDT
cat /tmp/journalctl.log | grep Host
Mar 28 09:19:08 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
Mar 28 09:19:18 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
Mar 28 09:19:28 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
gtiwari@localhost ~ $ 

Looks like some one has to enable the host .

Later further 

 cat /tmp/journalctl.log | grep -e bonding -e Host -e pair
Mar 28 09:19:08 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
Mar 28 09:19:18 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0x4
Mar 28 09:19:18 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x04
Mar 28 09:19:18 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 4
Mar 28 09:19:18 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
Mar 28 09:19:28 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0x4
Mar 28 09:19:28 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x04
Mar 28 09:19:28 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 4
Mar 28 09:19:28 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
Mar 28 09:19:38 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:19:38 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:19:38 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:19:45 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:19:45 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:19:45 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:19:51 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe

Mar 28 09:19:51 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:19:51 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:19:58 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:19:58 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:19:58 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:20:05 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:20:05 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:20:05 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:20:12 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:20:12 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:20:12 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:20:19 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:20:19 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:20:19 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:20:26 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:20:26 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:20:26 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:20:33 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe <<------------ bonding successfull 
Mar 28 09:20:45 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:bonding_request_new() Requesting bonding for 00:07:61:75:60:25
Mar 28 09:20:45 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:adapter_bonding_attempt() hci0 bdaddr 00:07:61:75:60:25 type 0 io_cap 0x01
Mar 28 09:20:46 sieve-deschouwer-co-za bluetoothd[4033]: plugins/autopair.c:autopair_pincb() device 00:07:61:75:60:25 (Logitech diNovo Edge) 0x2540
Mar 28 09:20:51 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding 0x55bb70704df0 status 0x00
Mar 28 09:20:51 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() Proceeding with service discovery
Mar 28 09:20:51 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:pair_device_complete() Success (0x00) <<--------------------------------------- pairing done here
Mar 28 09:20:51 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0x0 
Mar 28 09:20:51 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x00 <<----------------------- going again for bonding failed 

Even though pairing for the device successful looks like bonding is failing and device is continueouly going for discovering... which intern going to following function 

Which intern also proves by 

> HCI Event: Command Status (0x0f) plen 4                     [hci0] 237.700464
      Authentication Requested (0x01|0x0011) ncmd 1
        Status: Success (0x00)
> HCI Event: Link Key Request (0x17) plen 6                   [hci0] 237.701445
        Address: 00:07:61:75:60:25 (29530)
< HCI Command: Link Key Request Negat.. (0x01|0x000c) plen 6  [hci0] 237.701504
        Address: 00:07:61:75:60:25 (29530)
> HCI Event: Command Complete (0x0e) plen 10                  [hci0] 237.702469
      Link Key Request Negative Reply (0x01|0x000c) ncmd 1 <<-------------------
        Status: Success (0x00)
        Address: 00:07:61:75:60:25 (29530)

Which kind of looks like authentication issue to me..

Can you please try restarting the bluetooth.services by systemctl and see does this help.. Meanwhile I am further going through the reports ..

Gopal..
Comment 31 Berend De Schouwer 2017-04-08 06:50:31 EDT
To be clear:

0. suspend
1. Un-suspend
2. Unlock gui
3. Restart bluetooth.service
4. only then try to connect bluetooth keyboard
...
5. Do this 5 times, and check if the problem persists
Comment 32 gopal krishna tiwari 2017-04-12 00:59:30 EDT
Hi, 

I've tried with logitech k380 BT keyboard and apple mouse to reproduce this issue over FC-21 and FC-24  (tried manually as well) with all possible variations. But wasn't successful :( for me the both key board and mouse works all the time 

0. suspend
1. Un-suspend (resume)

Can you tell me more about how you are performing above two steps ?

Gopal...
Comment 33 Berend De Schouwer 2017-04-12 03:57:11 EDT
(In reply to gopal krishna tiwari from comment #29)

> Can you please try restarting the bluetooth.services by systemctl and see
> does this help.. Meanwhile I am further going through the reports ..
> 
> Gopal..


That seems to help.  I've gone a week on the Kingston dongle without a problem.  I'll see about adding a service to suspend.target/post
Comment 34 Berend De Schouwer 2017-04-12 04:03:24 EDT
(In reply to gopal krishna tiwari from comment #32)
> Hi, 
> 
> I've tried with logitech k380 BT keyboard and apple mouse to reproduce this
> issue over FC-21 and FC-24  (tried manually as well) with all possible
> variations. But wasn't successful :( for me the both key board and mouse
> works all the time 
> 
> 0. suspend
> 1. Un-suspend (resume)
> 
> Can you tell me more about how you are performing above two steps ?
> 
> Gopal...

I perform them thusly:

1. suspend
   a. move mouse to top-right corner
   b. hit button, drop down appears
   c. move mouse to power-off
   d. hit "alt" on the keyboard, power-off becomes suspend
   e. click mouse button

2. resume
   a. hit power button on laptop

I usually try to unlock the shell by typing on the bluetooth keyboard.  So that would be the first bluetooth traffic that the OS sees.

There's usually a relatively long time between the two.  At least 30 minutes, and frequently 12 hours.  That may make a difference in the power management on keyboard and mouse.

I wouldn't be surprised if it's hardware dependent.  It's worse on the built-in Realtek 8723be than the Kingston.
Comment 35 gopal krishna tiwari 2017-04-13 05:27:00 EDT
(In reply to Berend De Schouwer from comment #33)
> (In reply to gopal krishna tiwari from comment #29)
> 
> > Can you please try restarting the bluetooth.services by systemctl and see
> > does this help.. Meanwhile I am further going through the reports ..
> > 
> > Gopal..
> 
> 
> That seems to help.  I've gone a week on the Kingston dongle without a
> problem.  I'll see about adding a service to suspend.target/post

Great, thanks for the feedback. 

Gopal..
Comment 36 gopal krishna tiwari 2017-04-13 05:28:22 EDT
(In reply to Berend De Schouwer from comment #34)
> (In reply to gopal krishna tiwari from comment #32)
> > Hi, 
> > 
> > I've tried with logitech k380 BT keyboard and apple mouse to reproduce this
> > issue over FC-21 and FC-24  (tried manually as well) with all possible
> > variations. But wasn't successful :( for me the both key board and mouse
> > works all the time 
> > 
> > 0. suspend
> > 1. Un-suspend (resume)
> > 
> > Can you tell me more about how you are performing above two steps ?
> > 
> > Gopal...
> 
> I perform them thusly:
> 
> 1. suspend
>    a. move mouse to top-right corner
>    b. hit button, drop down appears
>    c. move mouse to power-off
>    d. hit "alt" on the keyboard, power-off becomes suspend
>    e. click mouse button
> 
> 2. resume
>    a. hit power button on laptop
> 
> I usually try to unlock the shell by typing on the bluetooth keyboard.  So
> that would be the first bluetooth traffic that the OS sees.
> 
> There's usually a relatively long time between the two.  At least 30
> minutes, and frequently 12 hours.  That may make a difference in the power
> management on keyboard and mouse.
> 
> I wouldn't be surprised if it's hardware dependent.  It's worse on the
> built-in Realtek 8723be than the Kingston.

Let me search realtek hardware to verify this.

Gopal...
Comment 37 Berend De Schouwer 2017-06-28 05:49:37 EDT
Problem persists in F26 Beta.
Comment 38 Berend De Schouwer 2017-10-06 02:30:42 EDT
Problem persists in F27 beta

Bluetoothd reports an additional problem:
Oct 06 08:14:30 sieve-deschouwer-co-za bluetoothd[6845]: connect error: Too many levels of symbolic links (40)

/var/lib/bluetooth contains no symbolic links, but it does contain 140 files.  I'm assuming the links are actually somewhere in /sys

Still often gets:
Oct 06 08:14:30 sieve-deschouwer-co-za bluetoothd[6845]: Can't get HIDP connection info


Extra notes: the "too many levels of links" only happens with the Kingston add-on dongle, not the built-in Realtek one.  This also means that so far I haven't gotten the Kingston to pair with anything in F27.

I have managed to get the Realtek to pair, but with the usual frustrations (need to re-pair a few times after un-suspend to get it working.)

Note You need to log in before you can comment on or make changes to this bug.