LinuxQuestions.org - NetworkManager forgets my VPN settings until I reboot

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - NetworkManager forgets my VPN settings until I reboot (https://www.linuxquestions.org/questions/linux-networking-3/networkmanager-forgets-my-vpn-settings-until-i-reboot-4175576986/)

NetworkManager forgets my VPN settings until I reboot

When I log out and log back in, sometimes NetworkManager forgets my VPN settings - nm-applet shows the wifi connection as normal (and it works) but click on it and "VPN Connections" offers only "Configure VPN" or "Disconnect VPN". It fails to show the VPN that normally lives there.

The only way I've found to get it back to normal is to reboot - and then it's fine until I log out again.

Any ideas?

I'm on Fedora 22 with i3 window manager.

Can you not simply disconnect and the reconnect again? I occasionally have my work PPTP VPN session break, and I'm forced to reconnect again. I've never bothered to monitor the connection, but one could with monitor NetworkManager like this

Code:

sudo journalctl -fu NetworkManager

That should help you capture what is occurring with the VPN session.

BTW, instead of rebooting, try restarting NetworkManager like this

Code:

sudo systemctl restart NetworkManager

Hmm, I should have mentioned that I tried that - it doesn't help. Nor does 'pkill nm-applet; nm-applet&'

Well, I wouldn't expect killing the nm-applet to work since it's just the front-end to NetworkManager, and it's the underlying network layer that needs to be restarted.

When I log out (KDE 4.14.18, openSUSE Leap) and then log back in my VPN connection is terminated, but this is what I would have expected anyway since it is not defined as a 'system' connection, but as a 'user' connection only. However, it does let me restart it without issue. I assume from your reference to 'nm-appet' that you're a Gnome user, and I wonder if Gnome is configured to remember sessions, and whether this influences the behaviour here. I think the 'gnome-tweak-tool' can be used to configure this?

Quote:

I'm on Fedora 22 with i3 window manager.

I missed this before, and I'm not familiar with i3. I did find this which may or may not be relevant...

https://faq.i3wm.org/question/2/how-...-i3/index.html

that link led me to look at ck-list-sessions:

<quote>
Also note that you need to have a proper ConsoleKit session running to be authorized to use NetworkManager. You can verify that using ck-list-sessions | grep is-local which should print is-local = TRUE. In case you see FALSE there, use a display manager like gdm to login and start i3. It will not work with xdm currently (as of 2012-06-04), unless you use a patched version.
</quote>

ck-list-sessions returns nothing for me (but NM is working presently). I don't know if it's a furphy or something I need to worry about.

i3 is pretty minimalist so I supply dbus from my .xinitrc file - so many things to worry about these days - consolekit, policykit, dbus ... and very little doco to go with them. It's just odd that it works in the first session after booting but forgets my VPN names when I restart X

Quote:

i3 is pretty minimalist so I supply dbus from my .xinitrc file - so many things to worry about these days - consolekit, policykit, dbus ... and very little doco to go with them. It's just odd that it works in the first session after booting but forgets my VPN names when I restart X

I can understand that it is a little annoying with it's behaviour in your i3 environment. I guess you could consider using NetworkManager's CLI interfaces (nmcli or nmtui) to control the connectivity instead, and I note that the page I linked to also suggests 'netctl' as another option.

nmcli is in the same position - it looks like it's NM itself which has lost track of the VPN.

Ah, so not listed by the following after logging back in?

Code:

nmcli con

nmcli is also unable to raise the VPN although it does see it:

Code:

4 20:58 achar:~/ $ nmcli con

NAME            UUID                                  TYPE            DEVICE 

ClubMotelWAP2  ad458fde-b563-44de-92d8-eebc5462226a  802-11-wireless  --    

Moldova        b3486ebf-7a48-43a7-992a-367e32ac56fe  802-11-wireless  --    

Anchors        d16a2574-d4f0-417c-b813-c7a802094388  802-11-wireless  --    

OPTUSVD3516090  e4950cd6-d5df-406f-a7ee-819005a4807c  802-11-wireless  --    

OPTUSVD39E6F00  fc5df664-8b70-4460-bc3a-b752d799eaeb  802-11-wireless  --    

NETGEAR38      bab09c5d-e84c-46d0-bb7d-29dbd07ebd45  802-11-wireless  --    

Beltsy 1        f6a4ad9e-0d1b-4eed-9780-e399d5710ee2  802-11-wireless  --    

NETGEAR28      d5607a2a-6692-427d-9b60-707a3f6c06af  802-11-wireless  --    

Jacara105S      e1720742-0450-4f85-a9a9-566d7bc8d416  802-11-wireless  --    

belkin.14e      8db02e62-cf37-4ddb-8887-f28059a34e5d  802-11-wireless  --    

Beltsy          aac37b3d-8b97-43c6-ad06-b494db7578b6  802-11-wireless  wlp3s0 

SG-A1401210807  859f817a-170f-4c4e-af58-69f9587720b9  802-11-wireless  --    

OPTUSVD337BBF0  31b52bff-6823-4261-9bb8-11dd8a7073a4  802-11-wireless  --    

Garry123        82293e63-54b6-4c12-8291-819035eb564b  802-11-wireless  --    

Moldova_2GEXT  66c5693c-0c25-4cb8-b713-c8b63e23725c  802-11-wireless  --    

p5p1            752690a4-3409-4269-8a32-37eed956f54e  802-3-ethernet  --    

Baroona        4a1fd9d9-5dde-46f5-ba37-2ebbd70be161  802-11-wireless  --    

NETGEAR        af17c026-40e2-4ca2-8af7-1c7d76824c93  802-11-wireless  --    

TP-LINK_E0C8D8  9a74d837-bdf4-4f5c-bf63-5436b59dd060  802-11-wireless  --    

OPTUSVD3BDB319  6c84e15c-e067-40e1-b67b-c788a1d81423  802-11-wireless  --    

Emcorp          37cc4235-3680-498d-981d-ac9265cb0a67  802-11-wireless  --    

FLINDERS_CAFE  0d67ac2e-67ab-4878-9767-be5f20f35018  802-11-wireless  --    

tun0            c3983f04-8ba0-452b-b0be-c4074b43fc35  generic          tun0  

TNS            d040a0b3-138a-42f1-8736-27093be8e226  vpn              wlp3s0 

belkin.14e 1    03bae80d-420d-4000-8b00-f19eff59c9f9  802-11-wireless  --    

0 20:58 achar:~/ $ nmcli con up TNS

Error: Connection activation failed: Connection 'TNS' is already active

4 20:59 achar:~/ $ ping tns

PING bhepple.win2k.corp.tnsi.com (xxx.xxx.xxx.xxx) 56(84) bytes of data.

^C

--- bhepple.win2k.corp.tnsi.com ping statistics ---

5 packets transmitted, 0 received, 100% packet loss, time 3999ms

Oh that's interesting - something just timed out, I got a notify-send message saying the connection failed and now I can connect again with nm-applet!!!

Now I'm getting somewhere with this - maybe I can force it _down_ with nmcli instead of trying to get it up.

Of course, I can't get the thing to fail now ... no matter how I log out and log in ...

Finally it failed again:

0 08:47 achar:~/ $ nmcli con
NAME UUID TYPE DEVICE
Beltsy aac37b3d-8b97-43c6-ad06-b494db7578b6 802-11-wireless wlp3s0

... so no sign of my other access points or my VPN

... I tried 'systemctl restart NetworkManager' but it didn't help

... no sign of the timeout event that reset things on 9th

Weirder and weirder ... although nmcli doesn't report anything but 'Beltsy', nm-applet reports my second access point 'Moldova' but not the VPN. When I try to connect to 'Moldova' I get a popup error:

Failed to add/activate connection
(32) No session found for uid 1545 (unknown)

(uid 1545 is me)

What does the following show when the connections are missing?

Code:

nmcli dev

Quote:

Weirder and weirder ... although nmcli doesn't report anything but 'Beltsy', nm-applet reports my second access point 'Moldova' but not the VPN. When I try to connect to 'Moldova' I get a popup error:

Failed to add/activate connection
(32) No session found for uid 1545 (unknown)

(uid 1545 is me)

That is an interesting finding. Some Gnome-related regression perhaps?

This might be useful...

Code:

loginctl list-sessions

loginctl session-status 1545

If it's a session-related issue, then next time it fails check nmci as root.

Code:

sudo nmcli con