Network Manager icon appears disconnected

[panorain]

Hello, I have installed Mint 19.1 Mate Desktop Edition on my computer.

1. Do you happen to know why after suspend/unsuspend of the computer 'Network Manager' icon appears disconnected even while it is not disconnected? I can still ping an address and use Internet browser.

2. Do you know if it is (recommended or better) to maintain wireless connectivity to use the following command:

Code: Select all

sudo iwconfig interface/device name power off

Thanks again.

[gm10]

Check this file, there's a good chance the network device you're using is listed as unmanaged (managed=false):

Code: Select all

/etc/NetworkManager/NetworkManager.conf

Set it to true and restart the service or your computer and you should be fine.

[panorain]

Thanks for your reply.

I edited the following file to what is shown below and rebooted the computer. I then suspended and unsuspended the computer. Network Manager still shows a 'disconnected icon' after resuming from suspend. Although command: (ping) and Firefox still do in fact work.

/etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=true

[device]
wifi.scan-rand-mac-address=no

Previously I ran the following commands:

Code: Select all

sudo sed -i 's/wifi.powersave = 3/wifi.powersave = 2/' /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

[connection]
wifi.powersave = 2
==========================================================================================

Code: Select all

sudo iwconfig wlp3s1 power off

iwconfig

enp0s25 no wireless extensions.

lo no wireless extensions.

wlp3s1 IEEE 802.11 ESSID:"CenturyLink4210"
Mode:Managed Frequency:2.437 GHz Access Point: FE:F5:28:9E:A6:A4
Bit Rate=48 Mb/s Tx-Power=20 dBm
Retry short limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=70/70 Signal level=-38 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:10 Missed beacon:0

I have rebooted the computer of course after all of this has been done.
Thank you for your reply.

[gm10]

ifupdown should be unmanaged actually, probably best to revert that. Your wireless settings are fine, it's no problem to disable the power saving there.

Also I seem to have glossed over the fact that you're getting the issue only after a resume, so it's something else, anyway. Sounds like a bug with the network manager applet instead. I have an idea though.

If you run

Code: Select all

inxi -N

it tells you the driver in use for your wifi. In the following command, replace YOURDRIVERHERE with the driver name you got from inxi, then run the whole thing (it's multi-line but a single command, best to copy & paste as a whole):

Code: Select all

sudo tee /lib/systemd/system-sleep/reset_network_driver <<'EOB'
#!/bin/sh
case $1 in
    pre)
        modprobe -r YOURDRIVERHERE
        ;;
    post)
        modprobe YOURDRIVERHERE
        ;;
esac
EOB

Afterwards run this:

Code: Select all

sudo chmod +x /lib/systemd/system-sleep/reset_network_driver

Then try if it helps (you don't need to reboot first). If it doesn't, then modify the first one by moving the modprobe -r line right after the post) and try again like that.

The idea is that we're unloading and re-loading the network driver. It's what I usually suggest when the network itself doesn't come up again after a resume but it should also trigger a refresh of NetworkManager itself.

If that still doesn't work, then we can try restarting NetworkManager upon resume instead, but let's try the above first.

PS: Did a little additional research and seems to be a known bug:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1575655
https://bugzilla.gnome.org/show_bug.cgi?id=767317
https://bugs.launchpad.net/ubuntu/+sour ... ug/1636282
The last one ends with a workaround quite similar to mine so that hopefully means that what I proposed above will work.

[panorain]

@gm10, Thanks for your help and research with this problem.

I have tried multiple variances on the above changes you suggested. Included are some screenshots of what I have tried. I have suspended/resumed after each instance. I will add that occasionally the computer does in fact fail to resume after being suspended.

Code: Select all

inxi -N

Network:
Device-1: Intel 82567V-2 Gigabit Network driver: e1000e
Device-2: Ralink RT2561/RT61 802.11g PCI driver: rt61pci

I did revert /etc/NetworkManager/NetworkManager.conf

• [main]
  plugins=ifupdown,keyfile
  
  [ifupdown]
  managed=false
  
  [device]
  wifi.scan-rand-mac-address=no

Nojoy1.png

Nojoy3.png

Nojoy4.png

I am only able to add 3 attachments at a time.

Edit: I have tested the following configuration also.

• sudo tee /lib/systemd/system-sleep/reset_network_driver <<'EOB'
  > #!/bin/sh
  > case $1 in
  > pre)
  > modprobe rt61pci
  > ;;
  > post)
  > modprobe -r rt61pci
  > ;;
  > esac
  > EOB
  [sudo] password for deb:
  #!/bin/sh
  case $1 in
  pre)
  modprobe rt61pci
  ;;
  post)
  modprobe -r rt61pci
  ;;
  esac
  deb@deb-B667:~$ ping 8.8.8.8
  connect: Network is unreachable

I did also enter this command in terminal

Code: Select all

sudo chmod +x /lib/systemd/system-sleep/reset_network_driver

Thanks also for the 3 links you provided in your last post. I have not read through them thoroughly as of yet. More suggestions are also certainly welcome.

Thanks again

[gm10]

Only the first screenshot is correct, all the other examples have the -r parameter as the last command, which means you end up with a disabled network driver. Only try the example I posted and then one where the post) has both of them but in this order:

Code: Select all

modprobe -r rt61pci
modprobe rt61pci

If it doesn't help it might also be a timing issue. Can you try this in a terminal after a resume to see if it makes a difference to run it later?

Code: Select all

sudo modprobe -r rt61pci
sudo modprobe rt61pci

Also try this to restart the whole NetworkManager, that should really do it:

Code: Select all

sudo systemctl restart NetworkManager

Might even be enough to simply restart the applet itself:

Code: Select all

killall nm-applet
nm-applet & disown

[panorain]

@gm10 Thank you for your response.

I currently do have the following settings set:

• deb@deb-B667:~$ sudo tee /lib/systemd/system-sleep/reset_network_driver <<'EOB'
  > #!/bin/sh
  > case $1 in
  > pre)
  > modprobe -r rt61pci
  > ;;
  > post)
  > modprobe rt61pci
  > ;;
  > esac
  > EOB
  [sudo] password for deb:
  #!/bin/sh
  case $1 in
  pre)
  modprobe -r rt61pci
  ;;
  post)
  modprobe rt61pci
  ;;
  esac

If it doesn't help it might also be a timing issue. Can you try this in a terminal after a resume to see if it makes a difference to run it later?

Code: Select all

sudo modprobe -r rt61pci
sudo modprobe rt61pci

Neither of the above commands show the Network Manager applet as connected after resume.

Code: Select all

sudo systemctl restart NetworkManager

Does in fact reenable the Network Manager applet connectivity status BUT it's like a hit/miss type of situation <----- (input command multiple times then finally applet appears connected) <----The disconnected and connected messages do appear in the top right corner of MATE.

Might even be enough to simply restart the applet itself:

Code: Select all

sudo modprobe -r rt61pci
sudo modprobe rt61pci

The above commands do in fact work to kill the applet and then display the applet again in the taskbar.

[gm10]

So restarting NetworkManager is hit or miss. Interesting. You didn't say whether reloading the applet alone was of any use?

[panorain]

Reloading the applet alone is of no use to display the applet connectivity status properly yet in another terminal ping works correctly. Also webbrowser works fine.

[panorain]

I apologize for double posting but I felt the need to add this also.

Multiple attempts to run ---->

Code: Select all

sudo systemctl restart NetworkManager

(nm-applet:5684): Gtk-CRITICAL **: 05:39:59.157: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed

(nm-applet:5684): Gtk-CRITICAL **: 05:39:59.157: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed

(nm-applet:5684): Gtk-WARNING **: 05:39:59.159: Can't set a parent on widget which has a parent

(nm-applet:5684): Gtk-CRITICAL **: 05:40:09.421: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed

(nm-applet:5684): Gtk-CRITICAL **: 05:40:09.421: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed

(nm-applet:5684): Gtk-WARNING **: 05:40:09.424: Can't set a parent on widget which has a parent

(nm-applet:5684): Gtk-CRITICAL **: 05:40:09.903: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed

(nm-applet:5684): Gtk-CRITICAL **: 05:40:09.903: gtk_widget_destroy: assertion 'GTK_IS_WIDGET (widget)' failed

(nm-applet:5684): Gtk-WARNING **: 05:40:09.905: Can't set a parent on widget which has a parent
^C

Then multiple attempts to restart applet fail entirely.

Thank You,

[gm10]

The errors are probably normal, that widget is notoriously buggy, it fills up your error log even on a good day.

I'm afraid I'm out of good ideas for now. I suggest you go through the bug reports I linked and see if they offer any other workarounds and try them out. Or otherwise just live with it I guess, it's just a display issue. Or maybe somebody else here has an idea, too.

[panorain]

@gm10, Thank you very much for your help with this problem I do appreciate it.