I have dual-booted Ubuntu 16.04.3 LTS and Windows 10 on my Surface Book, and on the Windows side I have no issues with the wireless internet at my work office. On my Ubuntu partition, it seems that sometimes when I switch access points, my wireless internet gets disconnected and is not able to connect to the same network or any other network until I restart my computer. This issue also occurs even when I haven't switched wireless access points. It's not consistent at all.

I've tried the solutions posted here, here, and here without any luck. This is a rather frustrating issue because the restart disrupts my workflow, as you can imagine.

I've looked at several other questions and tried their solutions without any luck. Any help would be greatly appreciated. Here is a link to my wireless-info.txt: https://ufile.io/abkfd

Update (February 9, 2018):

I'm not sure what changed, but a few weeks ago, my wireless internet stopped disconnecting when I switch access points! It's likely that one of the updates in the Software Updater fixed my internet issues.

Unfortunately, I don't have more details on the fix, but for all those running Ubuntu on their Surface Book devices, try installing the latest updates using the Software Updater!

Update (June 4, 2018):

I ran into this issue again after reformatting my computer a couple of months ago and have tried patching the kernel to 4.13 with no luck. My internet kept disconnecting, and my wireless bluetooth headphones couldn't connect effectively either.

I felt like I should upgrade the kernel to 4.15, but I needed to update OpenSSL. Instead of doing that manually, I decided to take the risk and upgrade to Ubuntu 18.04. Both of my problems were fixed by upgrading! My internet has been working wonderfully so far, and my bluetooth headphones are also perfectly functional.

I didn't have anything to lose if the upgrade didn't work and I had to reformat my computer again, so while I would recommend this route, be careful as the upgrade directly to Ubuntu 18.04 from 16.04 allegedly won't be officially supported until late July 2018.

  • Oh, which kernel are you using by the way? The normal 4.4 from Ubuntu? (uname -a to find out, apologies if you're not a beginner). Part of the fun of looking for solutions on /r/surfacelinux is people doing all kinds of patches and having (apparently) slightly different bugs... Sep 12 '17 at 17:06
  • I'm using the default installed kernel: 4.10.0-33-generic. I haven't made any modifications to it.
    – Alexander
    Sep 12 '17 at 17:22
  • Oh interesting. I was using a slightly patched 4.4 (4.4 seems to still be the default for me). I'll switch to the linux-image-generic-hwe-16.04 package to join you. Sep 12 '17 at 17:34
  • ...err...will probably do that over the weekend. It seems to introduce more unrelated breakage at first look. Good luck again for now. Sep 12 '17 at 17:42
  • When the Wifi is not working, what does rfkill list show? Sep 17 '17 at 15:08

I also finally ran out of patience a couple of days ago after passively tolerating the same problem for a while.

I know disabling power management is one of the suggestions you linked to having unsuccessfully tried, but it seems to be working for me so far (at least as a way of avoiding the actual bug while its cause is unclear)...

I've disabled it through editing /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf because all the /etc/pm stuff no longer works. systemd (which is now in charge of power management) ignores it (although the files are all still there from several packages 🙄) -- did you do the same? NetworkMangler now seems to be the thing which best takes precedence over everything else for this setting (based on some half-arsed experimentation).

Running iwconfig consistently yields Power management:off which confirms the change has at least taken effect.

Note for passers-by on the setting I'm talking about: in /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf. I changed wifi.powersave = 3 to 2. 3 means enabled. 2 means disabled. 0 and 1 are "set to default" and "do nothing". This isn't really documented. My source was a random gist.

That said, I've not lived with it for that long (just a couple of days) so it's possible this hasn't actually resolved anything. I'll check back in here if it hasn't. Best of luck!

  • Thanks for your response. The iwconfig command shows that power management is off, and my wifi.powersave setting is set to 3 as well. Disabling power management has not solved my problem unfortunately.
    – Alexander
    Sep 12 '17 at 16:52
  • (Set to 2, you mean?) Argh, well. I'll wait for mine to stop working again as well then, and then try something else... Did you get anything interesting-looking from less +G /var/log/syslog or dmesg? Sep 12 '17 at 16:56
  • Yes, I meant that I set it to 2. Thanks for the command! I'll check syslog the next time it happens and post anything interesting here.
    – Alexander
    Sep 12 '17 at 17:20
  • This is what I see in syslog when the WiFi disconnects: pastebin.com/m8RVYv1n
    – Alexander
    Sep 18 '17 at 16:32

When I know the name of the network, I use:

nmcli c up name-of-the-network

For the networks I use frequently I have scripts named "name-of-the-network" in ~/bin/. The script must be made executable with chmod +x <filename> For example:

#! /bin/sh
# The name of this file is: ~/bin/name-of-the-network
nmcli c up name-of-the-network

One potential limitation of nmcli is a dependency on NetworkManager (or it might be a feature). To see a list o the the networks managed by NetworkManger type:

nmcli connection
  • I'm afraid this might not be relevant. I've got a Surface Pro 4 with similar WiFi hardware and rather than being a problem with using nm-applet, this seems to be a driver/hardware malfunction. It loses the ability to successfully scan or connect to any networks regardless of what method is used. Sep 12 '17 at 16:45
  • Thanks for your response. I agree with @TomSpurling; I've used sudo service network-manager restart when the WiFi has disconnected, and it did not work. I will give this a try though, thanks!
    – Alexander
    Sep 12 '17 at 16:53
  • @Alexander My experience with hardware incompatibility versus driver/kernel is that the most reliable fix is waiting + enough knowledge to deal with reversions from time to time. All the tail chasing and manual reading is probably necessary so I gain the knowledge, but frustrating. Sep 13 '17 at 1:48
  • 1
    Update: I tried the nmcli command after my WiFi disconnected, and it couldn't establish a connection, as predicted.
    – Alexander
    Sep 14 '17 at 22:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.