Updated: May 13, 2016
If you're as unlucky as I am - although in my case it is purely by choice - then your laptop may have a Realtek Wireless card, in which case you're probably experiencing a load of problems. This is exactly what afflicts my Lenovo G50 machine: intermittent network freezes and other random problems. True for almost EVERY single distro out there.
I already showed you how to work around the network freeze issue in my article written for Trusty. Now that Ubuntu 16.04 is here, and the problem still persists, it is time to revisit the tutorial. Then, we will handle yet another manifestation of this issue, and that is the total loss of Wireless networking after waking from suspend. I mentioned this in the Xerus distro review, and now we elaborate.
Problem 1: Network freezes
This is a somewhat tricky issue that has been pestering Linux users for about five years now, in various guises, including a separate but related issue, with Ringtail and its wired network, a long time ago, in a galaxy far, far away. More recently, the problem manifests in all post-Trusty releases on the G50 host. The resolution of the issue is to create/open a module config file /etc/modprobe.d/rtl8723be.conf and add the following directive in it:
options rtl8723be fwlps=N ips=N
I have explained this in my dedicated guide for Ubuntu 14.04, and it is still valid and effective, which makes the problem a sad, sad one, because you would hope someone would bother to fix this once and for all. Alas, no.
Problem 2: No network after waking from suspend
This is a brand new issue that I have not encountered before on the G50 laptop, and so far, it seems limited to the Ubuntu 16.04 family, and not before. Lovely jubbly, regressions all the way. Anyhow, what happens, your network goes down. If you try to turn it on, you can't really, and no Wireless access points show in the list. The network drop down list may actually read Wi-Fi Network device not ready. So what now?
Most people may choose to reboot at this point - and yes, that's a valid fix. But a better one is to try to fix this without rebooting. Indeed, what you want to do is try to somehow restore the network functionality. Since we know the Realtek kernel module is wonky, and we have already hacked it with our modprobe file, let's continue in that direction.
An option you can always try is to remove the module from memory and then insert it. This can be done using the modprobe command, and you don't want to attempt this while any modules are in use. But since our network is down, we can. However, you do want to run the lsmod command first to see what gives.
The output may deceive you into believing that the Realtek (rtl) module is used, but it is not. Without trying the -f flag to force the removal, see if you can remove it:
modprobe -r rtl8723be
After this, the lsmod command should output not rtl-related lines.
lsmod | grep rtl
btrtl 16384 1 btusb
bluetooth 520192 29 bnep,btbcm,btrtl,btusb,rfcomm,btintel
This means the module has been successfully unloaded. Now, load it again, and after you do this, you should see your network kick back into action. Job done.
There you go, a wealth of useful information. This tutorial covers two separate scenarios, both manifesting around the same core issue. If you have a Realtek Wireless card that is not behaving well, like my G50 example, try the conf tweak first. Then, if that does not work, you might want to consider the modprobe trick. And then, if you ever encounter suspend and wake issues, you can create a script that unloads the modules, sleeps for a second or two, then re-inserts the module. That should be a decent workaround.
Anyhow, here we are, at the end of this article, and hopefully, you're happier now, because things are actually working for you. Not one, but two separate problems, and if you're really in a tight spot, the Trusty guide also explains how to compile. But ideally, you should never doing this. Only if you must, you have the tools. Off I go.