Bluetooth doesn't work after resuming from sleep, Ubuntu 18.04 LTS

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
13
down vote

favorite
5












Bluetooth earphones work fine until sleep. After resuming from sleep however, they appear to connect for a brief moment before disconnecting. On blueman, the error given is Resource temporarily unavailable. This issue arose only after updating to 18.04 LTS.



Here's the terminal output for lsusb:



Bus 001 Device 002: ID 8087:8001 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 004: ID 1bcf:0002 Sunplus Innovation Technology Inc.
Bus 002 Device 003: ID 04f2:b477 Chicony Electronics Co., Ltd
Bus 002 Device 002: ID 0a5c:21f1 Broadcom Corp. HP Portable Bumble Bee
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub






share|improve this question






















  • I have the same issue with JBL Go speaker and a fresh install of 18.04. Nothing like restarting bluetooth.service or removing btusb module and reinserting it again worked. I had to reboot.
    – solsTiCe
    May 14 at 17:11










  • I have the same problem, whenever resuming from sleep there is a chance ubuntu acts like there is no bluetooth at all (hence why restarting the service doesn't work). Sleeping and resuming again solves it sometimes.
    – Freguglia
    May 15 at 23:16










  • @K7AAY for some reason hibernate doesn't work at all, so I can't verify that.
    – Nikhil Sadasivan
    May 16 at 6:18










  • Please edit to include results from terminal for lsusb
    – Jeremy31
    May 16 at 11:30










  • Same problem here. I have to reboot to get the speakers working again.
    – user1945827
    May 17 at 12:56














up vote
13
down vote

favorite
5












Bluetooth earphones work fine until sleep. After resuming from sleep however, they appear to connect for a brief moment before disconnecting. On blueman, the error given is Resource temporarily unavailable. This issue arose only after updating to 18.04 LTS.



Here's the terminal output for lsusb:



Bus 001 Device 002: ID 8087:8001 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 004: ID 1bcf:0002 Sunplus Innovation Technology Inc.
Bus 002 Device 003: ID 04f2:b477 Chicony Electronics Co., Ltd
Bus 002 Device 002: ID 0a5c:21f1 Broadcom Corp. HP Portable Bumble Bee
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub






share|improve this question






















  • I have the same issue with JBL Go speaker and a fresh install of 18.04. Nothing like restarting bluetooth.service or removing btusb module and reinserting it again worked. I had to reboot.
    – solsTiCe
    May 14 at 17:11










  • I have the same problem, whenever resuming from sleep there is a chance ubuntu acts like there is no bluetooth at all (hence why restarting the service doesn't work). Sleeping and resuming again solves it sometimes.
    – Freguglia
    May 15 at 23:16










  • @K7AAY for some reason hibernate doesn't work at all, so I can't verify that.
    – Nikhil Sadasivan
    May 16 at 6:18










  • Please edit to include results from terminal for lsusb
    – Jeremy31
    May 16 at 11:30










  • Same problem here. I have to reboot to get the speakers working again.
    – user1945827
    May 17 at 12:56












up vote
13
down vote

favorite
5









up vote
13
down vote

favorite
5






5





Bluetooth earphones work fine until sleep. After resuming from sleep however, they appear to connect for a brief moment before disconnecting. On blueman, the error given is Resource temporarily unavailable. This issue arose only after updating to 18.04 LTS.



Here's the terminal output for lsusb:



Bus 001 Device 002: ID 8087:8001 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 004: ID 1bcf:0002 Sunplus Innovation Technology Inc.
Bus 002 Device 003: ID 04f2:b477 Chicony Electronics Co., Ltd
Bus 002 Device 002: ID 0a5c:21f1 Broadcom Corp. HP Portable Bumble Bee
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub






share|improve this question














Bluetooth earphones work fine until sleep. After resuming from sleep however, they appear to connect for a brief moment before disconnecting. On blueman, the error given is Resource temporarily unavailable. This issue arose only after updating to 18.04 LTS.



Here's the terminal output for lsusb:



Bus 001 Device 002: ID 8087:8001 Intel Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 004: ID 1bcf:0002 Sunplus Innovation Technology Inc.
Bus 002 Device 003: ID 04f2:b477 Chicony Electronics Co., Ltd
Bus 002 Device 002: ID 0a5c:21f1 Broadcom Corp. HP Portable Bumble Bee
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub








share|improve this question













share|improve this question




share|improve this question








edited May 16 at 16:08

























asked May 14 at 17:07









Nikhil Sadasivan

687




687











  • I have the same issue with JBL Go speaker and a fresh install of 18.04. Nothing like restarting bluetooth.service or removing btusb module and reinserting it again worked. I had to reboot.
    – solsTiCe
    May 14 at 17:11










  • I have the same problem, whenever resuming from sleep there is a chance ubuntu acts like there is no bluetooth at all (hence why restarting the service doesn't work). Sleeping and resuming again solves it sometimes.
    – Freguglia
    May 15 at 23:16










  • @K7AAY for some reason hibernate doesn't work at all, so I can't verify that.
    – Nikhil Sadasivan
    May 16 at 6:18










  • Please edit to include results from terminal for lsusb
    – Jeremy31
    May 16 at 11:30










  • Same problem here. I have to reboot to get the speakers working again.
    – user1945827
    May 17 at 12:56
















  • I have the same issue with JBL Go speaker and a fresh install of 18.04. Nothing like restarting bluetooth.service or removing btusb module and reinserting it again worked. I had to reboot.
    – solsTiCe
    May 14 at 17:11










  • I have the same problem, whenever resuming from sleep there is a chance ubuntu acts like there is no bluetooth at all (hence why restarting the service doesn't work). Sleeping and resuming again solves it sometimes.
    – Freguglia
    May 15 at 23:16










  • @K7AAY for some reason hibernate doesn't work at all, so I can't verify that.
    – Nikhil Sadasivan
    May 16 at 6:18










  • Please edit to include results from terminal for lsusb
    – Jeremy31
    May 16 at 11:30










  • Same problem here. I have to reboot to get the speakers working again.
    – user1945827
    May 17 at 12:56















I have the same issue with JBL Go speaker and a fresh install of 18.04. Nothing like restarting bluetooth.service or removing btusb module and reinserting it again worked. I had to reboot.
– solsTiCe
May 14 at 17:11




I have the same issue with JBL Go speaker and a fresh install of 18.04. Nothing like restarting bluetooth.service or removing btusb module and reinserting it again worked. I had to reboot.
– solsTiCe
May 14 at 17:11












I have the same problem, whenever resuming from sleep there is a chance ubuntu acts like there is no bluetooth at all (hence why restarting the service doesn't work). Sleeping and resuming again solves it sometimes.
– Freguglia
May 15 at 23:16




I have the same problem, whenever resuming from sleep there is a chance ubuntu acts like there is no bluetooth at all (hence why restarting the service doesn't work). Sleeping and resuming again solves it sometimes.
– Freguglia
May 15 at 23:16












@K7AAY for some reason hibernate doesn't work at all, so I can't verify that.
– Nikhil Sadasivan
May 16 at 6:18




@K7AAY for some reason hibernate doesn't work at all, so I can't verify that.
– Nikhil Sadasivan
May 16 at 6:18












Please edit to include results from terminal for lsusb
– Jeremy31
May 16 at 11:30




Please edit to include results from terminal for lsusb
– Jeremy31
May 16 at 11:30












Same problem here. I have to reboot to get the speakers working again.
– user1945827
May 17 at 12:56




Same problem here. I have to reboot to get the speakers working again.
– user1945827
May 17 at 12:56










4 Answers
4






active

oldest

votes

















up vote
16
down vote



accepted










update bluez to >=5.28.2



18.04 ships with a buggy bluez package for now; newer version is available from this PPA: https://launchpad.net/~bluetooth/+archive/ubuntu/bluez:



sudo add-apt-repository ppa:bluetooth/bluez
sudo apt install bluez



workaround for buggy Bluetooth applet (Unity specific?)



This is probably the issue @solstice mentioned - BT menu applet doesn't let me enable Bluetooth after resuming from sleep. No matter if the toggle switch is off or on, the BT icon is disabled, and rfkill output doesn't change:



$ rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
12: hci0: Bluetooth
Soft blocked: no
Hard blocked: no


You can toggle BT manually by running (substitute your own ID):



rfkill block 12
rfkill unblock 12


and BT applet should pick it up correctly now. At this point, you should be able to connect to your devices. For now I've hacked it together using a script that does this automatically after resume:



$ cat /lib/systemd/system-sleep/bt
#!/bin/sh

case $1 in
post)
sleep 5
rfkill block `rfkill list | grep hci | cut -d: -f1`
sleep 1
rfkill unblock `rfkill list | grep hci | cut -d: -f1`
;;
esac


The ID number next to hci0 in rfkill list output seems to increment after every suspend/resume. Disabling/enabling BT using the BT menu should change the output ('soft blocked: yes' for BT disabled via menu), but it doesn't. My guess is that the applet remembers the wrong device ID and is thus trying to enable a device that no longer exists.






share|improve this answer


















  • 1




    Just updating the bluez package did it for me, thank you!
    – Nikhil Sadasivan
    May 17 at 14:21










  • Same updating bluez worked like a charm!
    – Sanketh Katta
    May 18 at 2:35






  • 1




    Update: It only worked for 1 sleep cycle. However, after multiple, I am back to the same problem.
    – Sanketh Katta
    May 18 at 23:51










  • Unless the bug has already been fixed by an update, the bluez update worked for me.
    – user1945827
    May 19 at 10:56










  • Using the blueman applet (sudo apt install blueman) and updated bluez (from ppa) is working well for me.
    – Mark
    Jun 12 at 13:22


















up vote
1
down vote













Try in a terminal (no root needed)



btnum=`rfkill list|grep hci0| cut -f 1 -d ':'`
rfkill block $btnum
rfkill unblock $btnum


This might be related to a bug in gnome-control-center. Not sure. I have found this to work around that said bug and may be yours too.






share|improve this answer




















  • Unfortunately, this does not fix the issue for me. Thanks for sharing though!
    – Nikhil Sadasivan
    May 15 at 19:54

















up vote
1
down vote













For me this problem can be resolved by running



sudo service bluetooth restart


after waking from sleep






share|improve this answer



























    up vote
    0
    down vote













    The solution of upgrading to a newer version of bluez solved another problem for me of bluetooth connections disconnecting seconds after connecting, as described here: Ubuntu 18.04: Bluetooth device disconnects right after connect on Lenovo P50






    share|improve this answer




















      Your Answer







      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "89"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      convertImagesToLinks: true,
      noModals: false,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );








       

      draft saved


      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1036195%2fbluetooth-doesnt-work-after-resuming-from-sleep-ubuntu-18-04-lts%23new-answer', 'question_page');

      );

      Post as a guest






























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      16
      down vote



      accepted










      update bluez to >=5.28.2



      18.04 ships with a buggy bluez package for now; newer version is available from this PPA: https://launchpad.net/~bluetooth/+archive/ubuntu/bluez:



      sudo add-apt-repository ppa:bluetooth/bluez
      sudo apt install bluez



      workaround for buggy Bluetooth applet (Unity specific?)



      This is probably the issue @solstice mentioned - BT menu applet doesn't let me enable Bluetooth after resuming from sleep. No matter if the toggle switch is off or on, the BT icon is disabled, and rfkill output doesn't change:



      $ rfkill list
      0: phy0: Wireless LAN
      Soft blocked: no
      Hard blocked: no
      12: hci0: Bluetooth
      Soft blocked: no
      Hard blocked: no


      You can toggle BT manually by running (substitute your own ID):



      rfkill block 12
      rfkill unblock 12


      and BT applet should pick it up correctly now. At this point, you should be able to connect to your devices. For now I've hacked it together using a script that does this automatically after resume:



      $ cat /lib/systemd/system-sleep/bt
      #!/bin/sh

      case $1 in
      post)
      sleep 5
      rfkill block `rfkill list | grep hci | cut -d: -f1`
      sleep 1
      rfkill unblock `rfkill list | grep hci | cut -d: -f1`
      ;;
      esac


      The ID number next to hci0 in rfkill list output seems to increment after every suspend/resume. Disabling/enabling BT using the BT menu should change the output ('soft blocked: yes' for BT disabled via menu), but it doesn't. My guess is that the applet remembers the wrong device ID and is thus trying to enable a device that no longer exists.






      share|improve this answer


















      • 1




        Just updating the bluez package did it for me, thank you!
        – Nikhil Sadasivan
        May 17 at 14:21










      • Same updating bluez worked like a charm!
        – Sanketh Katta
        May 18 at 2:35






      • 1




        Update: It only worked for 1 sleep cycle. However, after multiple, I am back to the same problem.
        – Sanketh Katta
        May 18 at 23:51










      • Unless the bug has already been fixed by an update, the bluez update worked for me.
        – user1945827
        May 19 at 10:56










      • Using the blueman applet (sudo apt install blueman) and updated bluez (from ppa) is working well for me.
        – Mark
        Jun 12 at 13:22















      up vote
      16
      down vote



      accepted










      update bluez to >=5.28.2



      18.04 ships with a buggy bluez package for now; newer version is available from this PPA: https://launchpad.net/~bluetooth/+archive/ubuntu/bluez:



      sudo add-apt-repository ppa:bluetooth/bluez
      sudo apt install bluez



      workaround for buggy Bluetooth applet (Unity specific?)



      This is probably the issue @solstice mentioned - BT menu applet doesn't let me enable Bluetooth after resuming from sleep. No matter if the toggle switch is off or on, the BT icon is disabled, and rfkill output doesn't change:



      $ rfkill list
      0: phy0: Wireless LAN
      Soft blocked: no
      Hard blocked: no
      12: hci0: Bluetooth
      Soft blocked: no
      Hard blocked: no


      You can toggle BT manually by running (substitute your own ID):



      rfkill block 12
      rfkill unblock 12


      and BT applet should pick it up correctly now. At this point, you should be able to connect to your devices. For now I've hacked it together using a script that does this automatically after resume:



      $ cat /lib/systemd/system-sleep/bt
      #!/bin/sh

      case $1 in
      post)
      sleep 5
      rfkill block `rfkill list | grep hci | cut -d: -f1`
      sleep 1
      rfkill unblock `rfkill list | grep hci | cut -d: -f1`
      ;;
      esac


      The ID number next to hci0 in rfkill list output seems to increment after every suspend/resume. Disabling/enabling BT using the BT menu should change the output ('soft blocked: yes' for BT disabled via menu), but it doesn't. My guess is that the applet remembers the wrong device ID and is thus trying to enable a device that no longer exists.






      share|improve this answer


















      • 1




        Just updating the bluez package did it for me, thank you!
        – Nikhil Sadasivan
        May 17 at 14:21










      • Same updating bluez worked like a charm!
        – Sanketh Katta
        May 18 at 2:35






      • 1




        Update: It only worked for 1 sleep cycle. However, after multiple, I am back to the same problem.
        – Sanketh Katta
        May 18 at 23:51










      • Unless the bug has already been fixed by an update, the bluez update worked for me.
        – user1945827
        May 19 at 10:56










      • Using the blueman applet (sudo apt install blueman) and updated bluez (from ppa) is working well for me.
        – Mark
        Jun 12 at 13:22













      up vote
      16
      down vote



      accepted







      up vote
      16
      down vote



      accepted






      update bluez to >=5.28.2



      18.04 ships with a buggy bluez package for now; newer version is available from this PPA: https://launchpad.net/~bluetooth/+archive/ubuntu/bluez:



      sudo add-apt-repository ppa:bluetooth/bluez
      sudo apt install bluez



      workaround for buggy Bluetooth applet (Unity specific?)



      This is probably the issue @solstice mentioned - BT menu applet doesn't let me enable Bluetooth after resuming from sleep. No matter if the toggle switch is off or on, the BT icon is disabled, and rfkill output doesn't change:



      $ rfkill list
      0: phy0: Wireless LAN
      Soft blocked: no
      Hard blocked: no
      12: hci0: Bluetooth
      Soft blocked: no
      Hard blocked: no


      You can toggle BT manually by running (substitute your own ID):



      rfkill block 12
      rfkill unblock 12


      and BT applet should pick it up correctly now. At this point, you should be able to connect to your devices. For now I've hacked it together using a script that does this automatically after resume:



      $ cat /lib/systemd/system-sleep/bt
      #!/bin/sh

      case $1 in
      post)
      sleep 5
      rfkill block `rfkill list | grep hci | cut -d: -f1`
      sleep 1
      rfkill unblock `rfkill list | grep hci | cut -d: -f1`
      ;;
      esac


      The ID number next to hci0 in rfkill list output seems to increment after every suspend/resume. Disabling/enabling BT using the BT menu should change the output ('soft blocked: yes' for BT disabled via menu), but it doesn't. My guess is that the applet remembers the wrong device ID and is thus trying to enable a device that no longer exists.






      share|improve this answer














      update bluez to >=5.28.2



      18.04 ships with a buggy bluez package for now; newer version is available from this PPA: https://launchpad.net/~bluetooth/+archive/ubuntu/bluez:



      sudo add-apt-repository ppa:bluetooth/bluez
      sudo apt install bluez



      workaround for buggy Bluetooth applet (Unity specific?)



      This is probably the issue @solstice mentioned - BT menu applet doesn't let me enable Bluetooth after resuming from sleep. No matter if the toggle switch is off or on, the BT icon is disabled, and rfkill output doesn't change:



      $ rfkill list
      0: phy0: Wireless LAN
      Soft blocked: no
      Hard blocked: no
      12: hci0: Bluetooth
      Soft blocked: no
      Hard blocked: no


      You can toggle BT manually by running (substitute your own ID):



      rfkill block 12
      rfkill unblock 12


      and BT applet should pick it up correctly now. At this point, you should be able to connect to your devices. For now I've hacked it together using a script that does this automatically after resume:



      $ cat /lib/systemd/system-sleep/bt
      #!/bin/sh

      case $1 in
      post)
      sleep 5
      rfkill block `rfkill list | grep hci | cut -d: -f1`
      sleep 1
      rfkill unblock `rfkill list | grep hci | cut -d: -f1`
      ;;
      esac


      The ID number next to hci0 in rfkill list output seems to increment after every suspend/resume. Disabling/enabling BT using the BT menu should change the output ('soft blocked: yes' for BT disabled via menu), but it doesn't. My guess is that the applet remembers the wrong device ID and is thus trying to enable a device that no longer exists.







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited May 18 at 12:21

























      answered May 16 at 17:18









      Halka

      38627




      38627







      • 1




        Just updating the bluez package did it for me, thank you!
        – Nikhil Sadasivan
        May 17 at 14:21










      • Same updating bluez worked like a charm!
        – Sanketh Katta
        May 18 at 2:35






      • 1




        Update: It only worked for 1 sleep cycle. However, after multiple, I am back to the same problem.
        – Sanketh Katta
        May 18 at 23:51










      • Unless the bug has already been fixed by an update, the bluez update worked for me.
        – user1945827
        May 19 at 10:56










      • Using the blueman applet (sudo apt install blueman) and updated bluez (from ppa) is working well for me.
        – Mark
        Jun 12 at 13:22













      • 1




        Just updating the bluez package did it for me, thank you!
        – Nikhil Sadasivan
        May 17 at 14:21










      • Same updating bluez worked like a charm!
        – Sanketh Katta
        May 18 at 2:35






      • 1




        Update: It only worked for 1 sleep cycle. However, after multiple, I am back to the same problem.
        – Sanketh Katta
        May 18 at 23:51










      • Unless the bug has already been fixed by an update, the bluez update worked for me.
        – user1945827
        May 19 at 10:56










      • Using the blueman applet (sudo apt install blueman) and updated bluez (from ppa) is working well for me.
        – Mark
        Jun 12 at 13:22








      1




      1




      Just updating the bluez package did it for me, thank you!
      – Nikhil Sadasivan
      May 17 at 14:21




      Just updating the bluez package did it for me, thank you!
      – Nikhil Sadasivan
      May 17 at 14:21












      Same updating bluez worked like a charm!
      – Sanketh Katta
      May 18 at 2:35




      Same updating bluez worked like a charm!
      – Sanketh Katta
      May 18 at 2:35




      1




      1




      Update: It only worked for 1 sleep cycle. However, after multiple, I am back to the same problem.
      – Sanketh Katta
      May 18 at 23:51




      Update: It only worked for 1 sleep cycle. However, after multiple, I am back to the same problem.
      – Sanketh Katta
      May 18 at 23:51












      Unless the bug has already been fixed by an update, the bluez update worked for me.
      – user1945827
      May 19 at 10:56




      Unless the bug has already been fixed by an update, the bluez update worked for me.
      – user1945827
      May 19 at 10:56












      Using the blueman applet (sudo apt install blueman) and updated bluez (from ppa) is working well for me.
      – Mark
      Jun 12 at 13:22





      Using the blueman applet (sudo apt install blueman) and updated bluez (from ppa) is working well for me.
      – Mark
      Jun 12 at 13:22













      up vote
      1
      down vote













      Try in a terminal (no root needed)



      btnum=`rfkill list|grep hci0| cut -f 1 -d ':'`
      rfkill block $btnum
      rfkill unblock $btnum


      This might be related to a bug in gnome-control-center. Not sure. I have found this to work around that said bug and may be yours too.






      share|improve this answer




















      • Unfortunately, this does not fix the issue for me. Thanks for sharing though!
        – Nikhil Sadasivan
        May 15 at 19:54














      up vote
      1
      down vote













      Try in a terminal (no root needed)



      btnum=`rfkill list|grep hci0| cut -f 1 -d ':'`
      rfkill block $btnum
      rfkill unblock $btnum


      This might be related to a bug in gnome-control-center. Not sure. I have found this to work around that said bug and may be yours too.






      share|improve this answer




















      • Unfortunately, this does not fix the issue for me. Thanks for sharing though!
        – Nikhil Sadasivan
        May 15 at 19:54












      up vote
      1
      down vote










      up vote
      1
      down vote









      Try in a terminal (no root needed)



      btnum=`rfkill list|grep hci0| cut -f 1 -d ':'`
      rfkill block $btnum
      rfkill unblock $btnum


      This might be related to a bug in gnome-control-center. Not sure. I have found this to work around that said bug and may be yours too.






      share|improve this answer












      Try in a terminal (no root needed)



      btnum=`rfkill list|grep hci0| cut -f 1 -d ':'`
      rfkill block $btnum
      rfkill unblock $btnum


      This might be related to a bug in gnome-control-center. Not sure. I have found this to work around that said bug and may be yours too.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered May 14 at 17:29









      solsTiCe

      4,90221642




      4,90221642











      • Unfortunately, this does not fix the issue for me. Thanks for sharing though!
        – Nikhil Sadasivan
        May 15 at 19:54
















      • Unfortunately, this does not fix the issue for me. Thanks for sharing though!
        – Nikhil Sadasivan
        May 15 at 19:54















      Unfortunately, this does not fix the issue for me. Thanks for sharing though!
      – Nikhil Sadasivan
      May 15 at 19:54




      Unfortunately, this does not fix the issue for me. Thanks for sharing though!
      – Nikhil Sadasivan
      May 15 at 19:54










      up vote
      1
      down vote













      For me this problem can be resolved by running



      sudo service bluetooth restart


      after waking from sleep






      share|improve this answer
























        up vote
        1
        down vote













        For me this problem can be resolved by running



        sudo service bluetooth restart


        after waking from sleep






        share|improve this answer






















          up vote
          1
          down vote










          up vote
          1
          down vote









          For me this problem can be resolved by running



          sudo service bluetooth restart


          after waking from sleep






          share|improve this answer












          For me this problem can be resolved by running



          sudo service bluetooth restart


          after waking from sleep







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Jun 17 at 22:54









          trts

          163




          163




















              up vote
              0
              down vote













              The solution of upgrading to a newer version of bluez solved another problem for me of bluetooth connections disconnecting seconds after connecting, as described here: Ubuntu 18.04: Bluetooth device disconnects right after connect on Lenovo P50






              share|improve this answer
























                up vote
                0
                down vote













                The solution of upgrading to a newer version of bluez solved another problem for me of bluetooth connections disconnecting seconds after connecting, as described here: Ubuntu 18.04: Bluetooth device disconnects right after connect on Lenovo P50






                share|improve this answer






















                  up vote
                  0
                  down vote










                  up vote
                  0
                  down vote









                  The solution of upgrading to a newer version of bluez solved another problem for me of bluetooth connections disconnecting seconds after connecting, as described here: Ubuntu 18.04: Bluetooth device disconnects right after connect on Lenovo P50






                  share|improve this answer












                  The solution of upgrading to a newer version of bluez solved another problem for me of bluetooth connections disconnecting seconds after connecting, as described here: Ubuntu 18.04: Bluetooth device disconnects right after connect on Lenovo P50







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered May 18 at 8:54









                  Maarten

                  6810




                  6810






















                       

                      draft saved


                      draft discarded


























                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1036195%2fbluetooth-doesnt-work-after-resuming-from-sleep-ubuntu-18-04-lts%23new-answer', 'question_page');

                      );

                      Post as a guest













































































                      Popular posts from this blog

                      Unable to execute new pre-installation script (/var/lib/dpkg/tmp.ci/preinst)

                      Running the scala interactive shell from the command line

                      Do not install recommended packages of dependencies