GNOME Bugzilla – Bug 754372
[REGRESSION] Cannot re-connect to manually-configured (static IP) ethernet after suspend
Last modified: 2015-11-06 11:21:16 UTC
I recently upgraded from NetworkManager 1.0.4 to 1.0.6. After a suspend-resume cycle, I cannot connect to the internet. This only occurs with a specific ethernet connection. Wifi is fine, as is my "default" ethernet at home, but my work ethernet connection fails. It has a manually-specified IP address (and netmask, gateway and DNA servers). Here is more troubleshooting information, that may be useful. I see the tray icon go briefly red, then back to black, suggesting that the network is connected. Similarly, if I open the NetworkManager configuration window, it suggests that I am connected. Previously, on resume, I would see a double notification. The first would tell me that I had disconnected from the network, and the second would tell me I reconnected. I don't see this now. I only see a "disconnect" notification, and no "connect" notification. I can manually disconnect from the network and reconnect, which connects correctly, although this also does not give me the "connect" notification. After a broken network post-suspend, I attempted to restart Network Manager with `sudo systemctl restart NetworkManager` but this didn't help. I also attempted to pull the ethernet cord out and replace it, but this also failed. A full system restart fixed it. The other thing that worked was to manually select the "default" ethernet connection. This does not have a manual IP specified, and thus fails at work after several seconds. After a pause, the "work" ethernet automatically reconnects, and the internet is working! Again, there is no "connect" notification. Arch Linux KDE Plasma 5.4.0 NetworkManager 1.0.6 Here is a diff for the non-working and working connections, from `/etc/NetworkManager/system-connections/` --- Default 2015-08-21 00:14:20.412748788 +1000 +++ "Ethernet Work" 2015-09-01 12:17:32.206457245 +1000 @@ -1,8 +1,7 @@ [connection] -id=Ethernet -uuid=<removed> +id=Ethernet Work +uuid=<removed> type=ethernet -autoconnect=false permissions= secondaries= @@ -10,8 +9,10 @@ mac-address-blacklist= [ipv4] +address1=<removed>/<removed> +dns=<removed>;<removed>; dns-search= -method=auto +method=manual [ipv6] dns-search=
Ugh, the workaround involving attempting to connect to a non-static IP doesn't work all the time. I tested it twice before posting the bug, but after another suspend-resume it doesn't work any more. A full restart appears to be the only foolproof option. I also dual booted into (K)ubuntu to test NetworkManager (0.9.10.0). This worked fine, so it's not the network per se that's causing the problem.
Did you actually try to manually connect the "Ethernet Work" connection after resume? Did that work? It seems that you did not configure connection.autoconnect=yes for the connection in question. Is that intentional? If you don't do that, the connection will not be a candidate for autoconnect after resume. You can change that on the command line with: nmcli connection modify id "Ethernet Work" connection.autoconnect true
> Did you actually try to manually connect the "Ethernet Work" connection after resume? Did that work? According to the tray icon, I *am* connected, so I had to manually "disconnect" (which I got a notification for), then manually connect (which I got no notification for, but the tray icon suggested I was connected). This didn't connect me to the network properly. > It seems that you did not configure connection.autoconnect=yes for the connection in question. Is that intentional? > If you don't do that, the connection will not be a candidate for autoconnect after resume. In the KDE/Plasma GUI, I had selected "Automatically connect to this network when it is available". Is that the same thing? Previously that was sufficient for autoconnect after resume.
(In reply to bugzilla.gnome from comment #3) > > Did you actually try to manually connect the "Ethernet Work" connection after resume? Did that work? > > According to the tray icon, I *am* connected, so I had to manually > "disconnect" (which I got a notification for), then manually connect (which > I got no notification for, but the tray icon suggested I was connected). > This didn't connect me to the network properly. Please verify the status of the connection via: nmcli connection and nmcli device what does it give? What would you expect? If nmcli shows you the expected status, then it should be investigated what's up with the UI of plasma-nm... > > It seems that you did not configure connection.autoconnect=yes for the connection in question. Is that intentional? > > If you don't do that, the connection will not be a candidate for autoconnect after resume. > > In the KDE/Plasma GUI, I had selected "Automatically connect to this network > when it is available". Is that the same thing? Previously that was > sufficient for autoconnect after resume. That is the same thing. Please verify what nmcli connection show "Ethernet Work" nmcli connection show "default" gives. Is connection.autoconnect set properly?
>Please verify the status of the connection… I'm not at work currently, so I'll try tomorrow and report back. > Please verify what > > nmcli connection show "Ethernet Work" > nmcli connection show "default" > > gives. Is connection.autoconnect set properly? The former gives > connection.autoconnect: yes The latter gives > connection.autoconnect: no That is what I intended. (I use ethernet at work all every day and rarely at home.)
> Please verify the status of the connection… Both commands give the same output whether the network is properly connected or not. $ nmcli connection NAME UUID TYPE DEVICE Ethernet <removed> 802-3-ethernet -- Ethernet Work <removed> 802-3-ethernet enp10s0 $ nmcli device DEVICE TYPE STATE CONNECTION enp10s0 ethernet connected Ethernet Work wlp3s0 wifi disconnected -- lo loopback unmanaged -- I guess this suggests that NetworkManager thinks I am connected, even when I am not, and the plasma tray applet is consistent with this.
Unfortunately, I've since found that the workaround works inconsistently. That is, selecting the "wrong" default ethernet connection, and letting NetworkManager change back to the proper one will not always result in a working connection. Once this fails, I haven't gotten it to work again, and must reboot. I also tried troubleshooting more. I reverted to 1.0.4 and tested. This reconnects perfectly every time. I upgraded back to 1.0.6 and it failed again. I reverted again to 1.0.4 and it worked. (One minor point: I don't get the "connection" notification in 1.0.4 either, despite it working.) I also troubleshooted more in 1.0.6. I can't seem to get the network to reconnect, no matter how I stop and start NetworkManager. For example, when the network is broken, I manually disconnect, pull out the ethernet cable, then run `sudo systemctl stop NetworkManager`. I then run `sudo systemctl start NetworkManager`, reconnect the ethernet cable, and watch the auto-connection… but the network is still broken. However, restarting the computer works every time. Is there a foolproof way of restarting NetworkManager that should work?
The nmcli command output says you are connected. Let's see what is IP, routes and DNS information (when you say the connection is not working). $ ip addr $ ip route $ cat /etc/resolv.conf Also look at (or attach) NM logs showing the resume/suspend).
Sorry, in the two months since filing the bug, my workplace has moved to dynamic IP addresses, so I can't test the static IP regression anymore.