Ubuntu Wireless Internet Drop Off Fix

Ubuntu Wireless Internet Drop Off Fix

I’ll admit it. My ancient netbook and my wife’s 2010-era Macbook Pro don’t have any problem reconnecting to wifi after resuming from suspend on Ubuntu MATE 16.04. Sadly, however, I keep hearing of other people who, despite various updates, seem to still be struggling with it. Therefore, I’m going to offer two potential solutions that should help.

Before we get to that, you might be wondering why this is happening. Usually, wifi drops happen due to an over-saturated wifi channel in the area, heat at your wifi card/dongle or power management gone rogue. On some rare occasions, it can be the driver itself. But usually it’s one of the issues previously mentioned.

Option One – Turn off power management

This option is useful as it allows those with wifi cards that fail to resume a wifi connection after a suspend or simply drop the connection to your router every so often. There are two approaches to this: The first is used with Intel cards using iwlwifi – wireless cards like the Intel Dual Band Wireless-AC 7265, for example.

Note: Disabling power management will mean that you’ll have less battery life. But at least you know that you will have a better, more stable wireless connection.

Intel cards

For Intel cards using iwlwifi, you can try the steps below. But before we do any of those steps, let’s first verify this is in fact the driver you’re using.

sudo lshw -C network

Assuming you see something with driver= iwlwifi near the bottom of the text output from the terminal, you know you have the right driver. Let’s get started, shall we?

sudo modinfo -p iwlwifi

You should see something similar to the text below.

power_save:enable WiFi power management (default: disable) (bool)
power_level:default power save level (range from 1 - 5, default: 1) (int)

Now let’s backup our current configuration.

sudo cp /etc/modprobe.d/iwlwifi.conf /etc/modprobe.d/iwlwifi.bak

This will backup your iwlwifi.conf in case our changes screw things up somehow. Then, you can easily restore the file by doing the above in reverse, reboot and you’re back to the previous config.

Now that we have the backup in place, we’re ready to see if disabling power saving for the Intel wifi card helps.

echo "options iwlwifi 11n_disable=8" | sudo tee -a /etc/modprobe.d/iwlwifi.conf

Once added, reboot the computer and see if you experience any continued drop-offs or if wifi resumes correctly after a laptop suspend. The above command echoes the “options iwlwifi 11n_disable=8” statement into the right place for you. And this statement is designed to prevent iwlwifi from starting up the iwlwifi power management at each boot.

All other wifi cards

For those using something different than iwlwifi, not to worry as I have options for you as well. Yes, you could absolutely create conf files for each type of wifi card. But that’s an article unto itself. Perhaps another time. Instead, let’s just do this instead:

sudo lshw -C network

This will give you your “driver=driver-type.” In my case, it’s for a Ralink-powered dongle running the rt2800usb driver. The next step was to see if there is power saving functionality.

sudo modinfo -p rt2800usb

And that command gave me…

nohwcrypt:Disable hardware encryption. (bool)

According to the above terminal output, there isn’t as nothing even remotely close to “power saving” available. It could be that the driver simply doesn’t support it? Ignoring this, I ran the following I wanted to see for myself if this was accurate:


which gave me…

wlx001f1f4bbe66  IEEE 802.11bgn  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:on

So at least it registers that there is power management as an option! Let’s try to power management.

sudo iwconfig wlan0 power off

Then we run iwconfig again.

wlx001f1f4bbe66 IEEE 802.11bgn ESSID:off/any
          Mode:Managed Access Point: Not-Associated Tx-Power=20 dBm
          Retry short limit:7 RTS thr:off Fragment thr:off
          Power Management:off

Ah, it looks like despite the report that power savings wasn’t listed in the modinfo, there was indeed the ability to disable power management and thus, keep the wifi from timing out.

What we can learn from this is when you don’t know if your wireless supports power saving/management, try iwconfig to see if it’s “on.” If it is, run the power off command and then iwconfig again to see if it sticks. If successful, you can make this happen automatically at each boot.

Make power saving off the new default

Back in the terminal again, we’re going to change directories into the power management area.

cd /etc/pm/power.d

Now we’re going to literally recreate the power off option we did above, to make power management off the new default.

sudo nano /etc/pm/power.d/wireless

Once the new file is opened in the terminal, you will paste or type in this as follows.

/sbin/iwconfig wlx001f1f4bbe66 power off

Notice how we used the full path to iwconfig? That’s because in files like this, it needs the full path to run at start.

After saving this file, we need to make sure it’s executable. Otherwise all of this would have been for nothing.

sudo chmod +x /etc/pm/power.d/wireless

Important: Your wifi device might be something like eno2 or wlan0. Mine just happens to be wlx001f1f4bbe66. So pay careful attention to your wireless device’s designation when running the standard iwconfig.

Now you can reboot your computer and run iwconfig again to see if the power management remains off for your wireless device.

Option 2 – Restart Network Manager at boot up

So your wireless is still failing to reconnect after a laptop suspend on Ubuntu above and lo and behold, the problem isn’t the wireless card – it’s still network manager. Despite the fact that I can’t recreate this issue on Ubuntu MATE 16.04+ at all, I’ll take your word for it. Perhaps there is a regression of an older bug at work. No biggie, because I got your back. Here’s what we’re going to do…

Start off by Suspending your laptop and then waking it. Wifi fails to reconnect – no biggie. At this moment, I want you to run the following WITHOUT reconnecting to your wireless your wlan0 (or whatever it is).

sudo systemctl restart network-manager.service

You should notice network manager drop and then reconnect successfully to your wireless connection.

Tip: If the above fails to work, check in network manager that the following is enabled: “Automatically connect to this network when it is available” under the General tab. If not, check this, reboot and try the above steps again.

Now that we have the ability to restart network manager after a laptop suspend, we need to automate this after we wake up the laptop from suspend.

The first step is to create a new systemd service called wifi-skillz.service. Okay, you can actually call it-anything-you-want.service and it would work fine. But I like to make my custom services fun and easy to remember. Helps when checking on their status, etc.

Back in our old friend, the terminal, type or carefully paste the following.

sudo nano /etc/systemd/system/wifi-skillz.service

Next we’re going to drop the following into the nano file. Notice how this supports both sleep and suspend! Neat, right?

#sudo systemctl enable wifi-skillz.service
Description=Make wifi work after suspend

ExecStart=/bin/systemctl restart network-manager.service


Save the file, then we’ll need to enable it. Note, we’re not going to start the service as it’s only needed on a resume from suspend, not immediately.

sudo systemctl enable wifi-skillz.service

Assuming there isn’t any new weirdness and everything is typed out correctly, enabled and so forth, you should be good to go. Totally for the heck of it, you might consider restarting your laptop before testing this. Ideally, the enabling done previously should make network manager restart upon a resume from suspension, but I recommend a reboot as it forgoes any oddities going on.


Sadly, I make no promises here that this is absolutely going to work. Even on Chromebooks, stuff happens sometimes beyond our control. However, there are some considerations to look through.

Can’t disable power management – Getting wifi drops: If you’re using the additional driver manager or have a wireless device that doesn’t support power management changes, you may be unable to do anything here. If you’re getting frequent drops, try another device or another kernel. And finally, I know disabling power management for internal cards using native kernel drivers works. I can’t say the same for USB dongles. Some might, some might not remember to keep power management off when the laptop reboots.

The other consideration is mixed 802.11 mixed modes with some routers. Also, try changing the channel on your router itself. The former issue with mixed modes is extremely common and worth investigating. Try going 802.11N or whatever only, see if that provides a solution.

Network manager isn’t restarting after resuming from laptop suspend: First let’s check for errors with network manager.

grep -i networkmanager /var/log/syslog

And then check for errors with this command.

journalctl -fa

This acts as a tail -f /var/log/syslog, giving you the tail end of the systemd logs. You should see any systemd errors in this area if there was a failure to start. Also, verify after your last reboot that the service is still enabled.

sudo systemctl status wifi-skillz.service

This will tell you if it’s still enabled or not. If it’s not enabled, re-do it and then reboot the laptop. If the problem is persistent, double check your work from the “.service file” above that you created.

If you’re able to get it to reconnect, but find that DNS is doing strange things…check out this other article on fixing Ubuntu DNS challenges.

Matt Hartley
Freedom Penguin’s founder & talking head – Matt has over a decade working with Linux desktops, his operating system experience consists of both Windows and Linux operating platforms. In addition to writing articles on Linux and open source technology for Datamation.com and OpenLogic.com/wazi, Matt also once served as a co-host for a popular Linux-centric podcast.

Matt has written about various software titles, such as Moodle, Joomla, WordPress, openCRX, Alfresco, Liferay and more. He also has additional Linux experience working with Debian based distributions, openSUSE, CentOS, and Arch Linux.

12 thoughts on “Ubuntu Wireless Internet Drop Off Fix”

  1. I can’t WAIT to try this on the HP laptop we bought earlier this year. I’ve tried so many other “solutions”. It led to giving up and moving the wife back to the windows partition….Booooo! But I love my Mate!

    • Awesome. Assuming your wifi card is compatible, the issues are related to network manager not working on resume or power management issues on resume or with a dropped connection (randomly), THEN this should help.

      For dropped connections while using laptop, use Option 1. For Resume issues, I’d start with option 2. In both cases, I highly recommend using a behind the scenes program called tlp (TLP). I will have a separate article on it in the near future.

  2. I’ve suffered this problem on Ubuntu MATE up until about a month ago (I’ve switched distros). When I had this issue, it gave me the impression that the wifi card is simply not scanning for local networks. Ideally, what I think should happen is that when you wake up your laptop, Network Manager should refresh its list of local networks. That appears to me to be what is not happening. When I was running Ubuntu MATE, this was happening 2 out of every 3 times I resumed. However, after updates, the problem occurred much less frequently (about 1 out of every 20 resumes). So it definitely improved.

    While I think the network manager restart trick is sound and will probably work fine, I think the best fix for this would be to instead make it run whatever command Network Manager uses to refresh its wireless list. If that fixes it, then we’ve nailed the root cause. I’d test this myself, but I’m using Arch at the moment (no issues so far).

    • Hi Jay,

      The single biggest reason we relaunch the entire stack vs piece-mealing various stuff (like refresh its wireless list or other limited elements) is that it’s not a one size fixes all issue.

      The best benefit is the relaunch of NM actually does refresh the scanning as you described. Plus, today’s modern computers can relaunch the entire stack with barely any time added vs merely re-doing only one thing. My approach works for anyone having a NM issue. So even if there are new bugs introduced, odds are this fix will also be future proof. That’s why I tend to fix things with a heavier approach. They work now and often later as well.

      So in short, relaunching NM just addresses the issue vs assuming one cause vs one bug. It’s the safer, more reliable bet. Same approach when dealing with issues in Arch or any distro. Rather than fooling around with relaunching/activating a competent, refresh the stack and just make it doe its job. 🙂 Heavy handed perhaps, but the results work well.

      • Hi Matt,

        I do agree with you that it’s an approach more likely to fix a multitude of possible use-cases. However, we should also keep in mind that restarting Network Manager will also drop the wired connection (if one exists). Sometimes people use both for different purposes (such as VMs on one interface, Internet on another, especially when one NIC doesn’t support bridging). Of course, that’s rare, but I’ve seen it. I think we should be mindful that restarting such a service disrupts all NICs.

        I think your line of thinking works and is sound, but I’m merely suggesting that anything we can do to isolate the issue and discover the exact component failing, the more likely we are to find a root-cause that will fix the problem for everyone. Basically, giving back the open-source way. Sure, there may be many root-causes, but I’ve been following the bug reports on this, and the symptoms in every case seem evident that Network Manager isn’t always re-scanning. If a particular person doesn’t care and just wants this annoying problem fixed, then your way is definitely best. It’s also probably the best way for supporting other people’s installations that aren’t necessarily members of the community.

        On my end, I have one last machine running a flavor of Ubuntu (Ubuntu GNOME) with a wireless connection, and if this issue happens again, I’m going to use the refresh icon addon I’ve installed in GNOME (I forgot its name) and see if clicking that forces a refresh. If it does, I’ll maybe post on the bug report and see if we can get this fixed. I’d prefer for updates to come in via the official Ubuntu repositories to fix this for everyone, but I understand that will take some time. So anything we can do in order to help the community I think will only benefit us.

        • I’ve been following the bug reports on this, and the symptoms in every case seem evident that Network Manager isn’t always re-scanning.

          Been letting this percolate a bit more – especially on issue isolating. You’re right, this would be incredibly useful. And I wonder if the above resume script might not be able to be tweaked to start the network scanning perhaps? Could be an awesome option. I’ll definitely look into it and if successful, add this to the article. Great feedback!

          • Hi Matt,

            As fate would have it, I ran into this issue last night. My ex-wife was complaining that “WiFi wasn’t working” (she runs Ubuntu MATE) and when I woke it up from suspend, it didn’t automatically reconnect to wireless. Network Manager showed no connections being available. So, I ran this command:

            sudo iwlist wlp3s0 scan

            I’m pretty sure that’s the command I used, I basically just Googled for it. Anyway, as soon as I ran that command, it immediately reconnected to the wireless network. If I can find some available time this week, I may be able to throw that into a systemd unit.

          • Nice! Yeah, that should work in a systemd unit for sure. It would just execute the command as it comes out of suspend. Nice share!

          • I stumbled across an easier way, thanks to System76. Store the following script at /lib/systemd/system-sleep/wifi_dropout_fix and mark it executable:


            set -e

            if [ “$2” = “suspend” ] || [ “$2” = “hybrid-sleep” ]; then
            case “$1” in
            pre) true ;;
            post) sleep 1 && service network-manager restart ;;

            I borrowed that code from the System76 driver repo. It’s what they’re doing for 16.04 currently. Basically, scripts located in /lib/systemd/system-sleep are executed automatically during the appropriate time, no need for a service to be written.

          • Interesting. Certainly good to have a non-service alternative. That said, I’ve had better reliability with setup services than with dropping in scripts. But if this works, then that’s fantastic. 🙂

Leave a Comment