After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 780387 - On standby then resume applet "connects" automatically to OpenVPN, but doesn't set the route
On standby then resume applet "connects" automatically to OpenVPN, but doesn'...
Status: RESOLVED DUPLICATE of bug 779768
Product: NetworkManager
Classification: Platform
Component: VPN: openvpn
1.6.x
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-03-22 09:20 UTC by Najjar
Modified: 2017-03-29 18:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
NM journalctl output (263.03 KB, text/plain)
2017-03-23 14:48 UTC, Najjar
Details

Description Najjar 2017-03-22 09:20:48 UTC
I'm using KDE Plasma, and filed a bug in KDE's, but I was told that I should file it here because it's a NetworkManager bug, not a Plasma applet one (https://bugs.kde.org/show_bug.cgi?id=377784)

I'm on Arch, using Plasma

When resuming, the applet will reconnect to the connections set to automatically connect to. If a connection (e.g. WiFi) is set to automatically connect to another OpenVPN connection, on resume it'll connect, and show the connected icon, but the route isn't set and checking the IP reveals the ISP's (and route command shows that it isn't set).

I need to disconnect, then reconnect again (VPN connection) for the route to be established correctly and work as expected.

This problem isn't present when Plasma starts for the first time (i.e. on boot)

1) Go to sleep
2) Resume
3) plasma-nm will attempt to connect to WiFi, LAN, etc. And will attempt to connect to the VPN connection tied to the connection (say WiFi)
4) plasma-nm will show "connecting" and take the usual time to connect to VPN
5) "Connected" lock icon will appear
6) Checking the IP in browser reveals the original (ISP) IP
7) Disconnect the VPN connection, then connect again, the IP check is now showing the VPN's IP

Latest kernel, Plasma, and OVPN packages from Arch repos: plasma-nm 5.9.3, plasma-framework 5.32.0, openvpn 2.4.0, networkmanager 1.6.2, networkmanager-openvpn 1.2.8
Comment 1 Beniamino Galvani 2017-03-22 15:27:20 UTC
I can't reproduce this; can you please run 'nmcli general logging level TRACE' as root, perform a suspend/resume and attach logs of the resume?
Comment 2 Najjar 2017-03-23 13:15:24 UTC
Where does NM keep its logs?
Comment 3 Beniamino Galvani 2017-03-23 13:27:44 UTC
(In reply to Najjar from comment #2)
> Where does NM keep its logs?

Usually in the journal; try 'journalctl -u NetworkManager -b'.

Or, if the distro doesn't use journald, in syslog (somewhere in /var/log/, depending on configuration).
Comment 4 Najjar 2017-03-23 14:48:28 UTC
Created attachment 348574 [details]
NM journalctl output

Here's the log. In this instance, after resuming it "connected" (as described above); when I disconnected and connected again, it did the same thing (i.e. didn't set a route); then I disconnected again and reconnected and the route was set correctly
Comment 5 Beniamino Galvani 2017-03-23 17:17:01 UTC
This is likely the same problem as bug 779768, which is due to a bug in kernel >= 4.10.

The git tree of NM has a workaround for the problem.

I'm closing this, please reopen if needed.

*** This bug has been marked as a duplicate of bug 779768 ***
Comment 6 Najjar 2017-03-29 18:43:55 UTC
I don't see the issue with kernel 4.10.5 anymore.