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 saturated wifi channel in 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:
iwconfig
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.
#!/bin/sh
/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.
Because we have systemd installed and running on Ubuntu 16.04 (and up), we might as well utilize it to give network manager a kick in the butt. 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?
#/etc/systemd/system/wifi-skillz.service
#sudo systemctl enable wifi-skillz.service
[Unit]
Description=Make wifi work after suspend
After=suspend.target
After=hibernate.target
After=hybrid-sleep.target
[Service]
Type=oneshot
ExecStart=/bin/systemctl restart network-manager.service
[Install]
WantedBy=suspend.target
WantedBy=hibernate.target
WantedBy=hybrid-sleep.target
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.
Troubleshooting
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.
The post Ubuntu Wireless Internet Drop Off Fix appeared first on Freedom Penguin.
from Freedom Penguin http://ift.tt/2hyq5mq
via
IFTTT
