Bluetooth devices are randomly disconnected

[0815pascal]

Since installing Zorin OS 16 (core) I'm having the problem that my bluetooth devices (keyboard and mouse) randomly disconnect. I can't say exactly when this happens, as I'm mostly using Zorin OS as a personal web server and so it stays on for 24/7 but it happens for sure in a timespan of within 24 hours.

Oddly enough, it's most of the times the mouse (Logitech MX3) that disconnects, but the keyboard (Logitech MX Keys) are still working. This is even more weird because in the settings-menu it says that Bluetooth was off while it's clearly not, as I'm still able to use my bluetooth-keyboard.

Furthermore, when trying to reconnect the mouse, the settings-app would crush on this screen:

And most strangely, I can see in the device-overview a huge list of other devices which have all the same name. As I'm using a Zenfone I'm not sure if it's my phone that somehow keeps on registering itself as a new device...what I do is that I would sometimes plug in my phone on a USB-cable in order to charge it but that's all (voluntary) interaction between my phone and Zorin.

In terminal I would run bluetoothctl and what happened was that it spit out an endless list with devices and it wouldn't stop, event when hitting ctrl + c it would continue to do so. Is this a normal behavior, i.e. it pools nearby devices repeatedly and therefore I see continuosly new values appearing (MAC-addresses are repeating, but the connection strength values are changin) ? But surely it should stop doing so once I cancel it with ctrl + c but it just ignores it and keeps on printing new lines.

Any ideas to what issue this could be related?

System:

• HP EliteDesk 800 G3 Mini     
  

• Zorin OS 16.3
  

• OS Type: 64-bit
  

• Windowing System: X11
  

• Graphics: Mesa Intel® HD Graphics 630 (KBL GT2)
  

• Processor: Intel® Core™ i5-7500 CPU @ 3.40GHz × 4
  

• Memory: 15.5 GB
  

[Aravisian]

@0815pascal

In terminal I would run bluetoothctl and what happened was that it spit out an endless list with devices and it wouldn't stop, event when hitting ctrl + c it would continue to do so. Is this a normal behavior,

No, that is not normal.

Can you please post the terminal output of:

sudo lshw -C network

[0815pascal]

Thanks for your answer and sure, this is the output when running sudo lshw -C network:

  *-network                 
       description: Wireless interface
       product: Wireless 8265 / 8275
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@0000:01:00.0
       logical name: wlp1s0
       version: 78
       serial: 44:03:2c:eb:39:0d
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi driverversion=5.15.0-79-generic firmware=36.77d01142.0 8265-36.ucode ip=192.168.178.30 latency=0 link=yes multicast=yes wireless=IEEE 802.11
       resources: irq:134 memory:e0100000-e0101fff
  *-network
       description: Ethernet interface
       product: Ethernet Connection (5) I219-LM
       vendor: Intel Corporation
       physical id: 1f.6
       bus info: pci@0000:00:1f.6
       logical name: eno1
       version: 00
       serial: ac:e2:d3:0c:1b:a8
       capacity: 1Gbit/s
       width: 32 bits
       clock: 33MHz
       capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=5.15.0-79-generic firmware=0.1-4 latency=0 link=no multicast=yes port=twisted pair
       resources: irq:127 memory:e0200000-e021ffff
  *-network:0
       description: Ethernet interface
       physical id: 2
       logical name: veth21254b7
       serial: 4e:50:02:43:ea:22
       size: 10Gbit/s
       capabilities: ethernet physical
       configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s
  *-network:1
       description: Ethernet interface
       physical id: 3
       logical name: veth506834d
       serial: c2:7b:81:07:b0:ff
       size: 10Gbit/s
       capabilities: ethernet physical
       configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s
  *-network:2
       description: Ethernet interface
       physical id: 4
       logical name: veth90f5503
       serial: 26:7d:df:b6:50:a7
       size: 10Gbit/s
       capabilities: ethernet physical
       configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s
  *-network:3
       description: Ethernet interface
       physical id: 5
       logical name: vethd12aff7
       serial: 2e:d6:da:b6:91:43
       size: 10Gbit/s
       capabilities: ethernet physical
       configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s
  *-network:4
       description: Ethernet interface
       physical id: 6
       logical name: vethddb511a
       serial: fa:01:da:7a:30:e3
       size: 10Gbit/s
       capabilities: ethernet physical
       configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s
  *-network:5
       description: Ethernet interface
       physical id: 7
       logical name: vethae23fdf
       serial: ba:6c:62:1a:18:2a
       size: 10Gbit/s
       capabilities: ethernet physical
       configuration: autonegotiation=off broadcast=yes driver=veth driverversion=1.0 duplex=full link=yes multicast=yes port=twisted pair speed=10Gbit/s

As a sidenode, I'm running docker and hence why I assume the many network interfaces.

Plus I have to add that it was stable over the last couple of days and so I wasn't sure if the problem was caused by a bug in a dependency that has been solved in the meantime by an update.

[0815pascal]

Thanks, I didn't know that Ctrl + z acts as a kill switch, good to know!
And good point about power management for Bluetooth. I did discover this in my Power settings but I'm not sure how to interpret it.

Does it mean that because the switch is active the power management can turn Bluetooth off? I did once deactivate the switch but then my Bluetooth-devices stopped working, so I assumed that it's just another switch to turn on/off Bluetooth.

Or is there somewhere else a setting where I can disable power management for BT? Thanks again!

[Aravisian]

@0815pascal

Does it mean that because the switch is active the power management can turn Bluetooth off?

Yes. Switching that to the off position will prevent BT from being disabled when on Notebook Computer Battery.

@0815pascal

Or is there somewhere else a setting where I can disable power management for BT? Thanks again!

For all wifi/radio:

sudo nano /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

The default:

[connection]
wifi.powersave = 3

Change the value to 2 so that it is exactly:

[connection]
wifi.powersave = 2

Tap ctrl+o to overwrite, then enter key to save. Tap ctrl+x to exit the editor.

@0815pascal

Plus I have to add that it was stable over the last couple of days and so I wasn't sure if the problem was caused by a bug in a dependency that has been solved in the meantime by an update.

Do you mean by this that BT is now behaving properly and may have been addressed in a recent updated package?