Second suspend-to-ram kills wifi

[Mister Pi]

On Kubuntu 18.04 with 4.15.0-32-generic running an Intel Wireless 7265 with the iwlwifi driver (driverversion=4.15.0-32-generic), suspend-to-RAM followed by wakeup will kill wireless the second time. The first suspend/wakeup is OK, but the second time, the Networks box (from clicking the network icon on the toolbar) shows nothing, neither my router nor any other routers in my neighborhood.

In the past, when I've had problems like this, I sometimes could get it to work by turning on airplane mode (in the Networks box) and turning it off again, or trying other controls in the Networks box. But nothing like this works anymore.

Assuming this is some kind of driver issue and I need to wait for a fix, is there a quick workaround (short of rebooting) I can use in the meantime? For instance, I see a process:

$ ps aux | grep wifi
root 482 0.0 0.0 0 0 ? S 11:09 0:03 [irq/131-iwlwifi]

Is there some kind of signal I can send to this process ("sudo kill SIGwhatever 482") or some other mechanism to reset the driver so it starts up again without having to reboot?

[GreyGeek]

You can try KSysMonitor's PID listing and right mouse on that line. Then select the kill signal to send to it.
Or, you can open a Konsole and use the kill command:
sudo kill -9 482
If you own the process then sudo is not necessary.

:~$ kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

[Mister Pi]

You can try KSysMonitor's PID listing and right mouse on that line. Then select the kill signal to send to it.

I can get the PID from ps. The point is, which signal do I send? Various programs are coded to respond to signals in various ways, and some provide a way to restart or reset the program at some level by sending it a specific signal. But without knowing about the particular driver, how do I know which signal?

Or, you can open a Konsole and use the kill command:
sudo kill -9 482

Then how do I restart it? Or will the OS do that automatically?

[Mister Pi]

BTW, I searched around and found some pages with other suggestions. Some of these are probably outdated (Ubuntu versions several years old), but anyway, I tried these and none of these worked:

sudo service network-manager restart

sudo systemctl restart NetworkManager

sudo nmcli networking off
sudo nmcli networking on

sudo iwconfig wlp1s0 txpower off
sudo iwconfig wlp1s0 txpower on

nmcli radio wifi off
nmcli radio wifi on

sudo ifconfig wlp1s0 down
sudo ifconfig wlp1s0 up

For the last pair, the "up" command responded with

SIOCSIFFLAGS: Input/output error

I don't know if that means anything, but maybe it means the driver is broken at some deep level.

(BTW, when the wifi is working properly, and I run the ifconfig command pair as shown, I don't get the error. After the first command, the wifi goes down, as expected. What is interesting is that if I click on the wifi icon in the toolbar, and get the Networks notification popup, all the other available wifi's in my neighborhood disappear, as expected. Yet it still shows my router and says it's connected, even after a minute. It seems not to recognize that the network is down. When I execute the "up" command, all the other wifi's appear again. Is this a bug in that program, or is it just understood that that tool is only an approximation?)

[GreyGeek]

Does rfkill show any blocks?

:~$ rfkill list
0: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no
1: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: acer-wireless: Wireless LAN
        Soft blocked: no
        Hard blocked: no
3: acer-bluetooth: Bluetooth
        Soft blocked: no
        Hard blocked: no

[Mister Pi]

Does rfkill show any blocks?

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

[Mister Pi]

It seems like this problem has disappeared. I noticed just before the kernel updated to 34 that it didn't seem to be happening anymore. The firmware on the driver hasn't been updated, so I'm not sure what was changed.

[kc1di]

Another way that worked for me a time or two is to restart Network Manager with this command:

systemctl restart NetworkManager

But I too found when the last kernel update happened the problem seems to have gone away.