GNOME.org
 

Re: networkmanager starts infinite number of VPN daemons

On Fri, 2016-01-22 at 15:24 +0100, Thomas Haller wrote:

On Fri, 2016-01-22 at 14:48 +0100, Adrian Freihofer wrote:

Hi,

Setup an OpenVPN connection with NetworkManager 1.0.10 is not
always painless... I ended up with a setup where an
infinite number of openvpn daemons tried to connect to one single
server.
The problem seems to be that NetworkManager does not (or at least
not
in any case) stop a VPN connection (stop the
openvpn daemon) to a particular remote before setting up a new VPN
connection (start an openvpn daemon) to the same
remote.


"systemd-cgls" shows many openvpn processes (most lines deleted)

├─1 /sbin/init
└─system.slice
...
  ├─NetworkManager.service
  │ ├─ 466 /usr/sbin/NetworkManager --no-daemon
  │ ├─1278 /usr/sbin/openvpn --remote nemp-server 1194 udp --comp
-lzo 
--nobind --dev tun --cipher BF-CBC --auth-nocache
--remote-cert-tls server --reneg-sec 0 --syslog nm-openvpn --script
-
security 2 --up /usr/lib/networkmanager-openvpn/nm-
openvpn-service-openvpn-helper --tun -- --up-restart --persist-key 
--
persist-tun --management
/var/run/NetworkManager/nm-openvpn-6aa02150-6f4f-4677-b53f-
46b464487246 unix --management-client-user root --management-
client-group root --management-query-passwords --auth-retry
interact
--route-noexec --ifconfig-noexec --client --ca
/etc/openvpn/nempkeys/ca.crt --cert /etc/openvpn/nempkeys/I-
mDeqEu.crt --key /etc/openvpn/nempkeys/I-mDeqEu.key --user
nm-openvpn --group nm-openvpn
  │ ├─2469 /usr/sbin/openvpn --remote nemp-server 1194 udp --comp
-lzo 
--nobind --dev tun --cipher BF-CBC --auth-nocache
--remote-cert-tls server --reneg-sec 0 --syslog nm-openvpn --script
-
security 2 --up /usr/lib/networkmanager-openvpn/nm-
openvpn-service-openvpn-helper --tun -- --up-restart --persist-key 
--
persist-tun --management
/var/run/NetworkManager/nm-openvpn-6aa02150-6f4f-4677-b53f-
46b464487246 unix --management-client-user root --management-
client-group root --management-query-passwords --auth-retry
interact
--route-noexec --ifconfig-noexec --client --ca
/etc/openvpn/nempkeys/ca.crt --cert
/etc/openvpn/nempkeys/RVg4sR2b.crt --key
/etc/openvpn/nempkeys/RVg4sR2b.key --user
nm-openvpn --group nm-openvpn
  │ ├─2600 /usr/lib/networkmanager-openvpn/nm-openvpn-service
  │ ├─3296 /usr/sbin/openvpn --remote nemp-server 1194 udp --comp
-lzo 
--nobind --dev tun --cipher BF-CBC --auth-nocache
--remote-cert-tls server --reneg-sec 0 --syslog nm-openvpn --script
-
security 2 --up /usr/lib/networkmanager-openvpn/nm-
openvpn-service-openvpn-helper --tun -- --up-restart --persist-key 
--
persist-tun --management
/var/run/NetworkManager/nm-openvpn-6aa02150-6f4f-4677-b53f-
46b464487246 unix --management-client-user root --management-
client-group root --management-query-passwords --auth-retry
interact
--route-noexec --ifconfig-noexec --client --ca
/etc/openvpn/nempkeys/ca.crt --cert /etc/openvpn/nempkeys/9-
hJsBlB.crt --key /etc/openvpn/nempkeys/9-hJsBlB.key --user
nm-openvpn --group nm-openvpn
...



"ip address" shows many tun devices, some of them with equal IP
addresses!
...
10: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc pfifo_fast
qlen 100
    link/[65534] 
17: tun2: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc pfifo_fast
qlen 100
    link/[65534] 
20: tun3: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast qlen 100
    link/[65534] 
    inet 10.42.0.146 peer 10.42.0.145/32 brd 10.42.0.146 scope
global
tun3
       valid_lft forever preferred_lft forever
22: tun4: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast qlen 100
    link/[65534] 
    inet 10.42.0.146 peer 10.42.0.145/32 brd 10.42.0.146 scope
global
tun4
       valid_lft forever preferred_lft forever
23: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast qlen 100
    link/[65534] 
    inet 10.42.0.150 peer 10.42.0.149/32 brd 10.42.0.150 scope
global
tun1
       valid_lft forever preferred_lft forever
25: tun6: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast qlen 100
    link/[65534] 
    inet 10.42.0.150 peer 10.42.0.149/32 brd 10.42.0.150 scope
global
tun6
       valid_lft forever preferred_lft forever
...



How to reproduce?
My application basically creates two connections using
NetworkManager's dbus interface: Ethernet + WLAN. Then it creates
a VPN connection without explicitly specifying the interface used
for
VPN. NetworkManager does what it is expected to
do: Successfully setup the VPN. After that I remove the WLAN or the
Ethernet connection (autoconnect=False) and I
replace the VPN configuration (new credentials, remote
configuration
remains) several times.

So far I do not understand which of the steps is the critical one.
Before I try to solve the problem "somehow", I would
like to ask if somebody understands the described behavior based on
the source code. May be somebody of you experts
could provide a patch I can test or give me a hint how I could fix
it?


Hi Adrian,


sounds like a bug.

Can you send the logfile with debugging enabled?

For that edit /etc/NetworkManager/NetworkManager.conf to have

  [logging]
  level=DEBUG

and restart NM.
Then `journal -u NetworkManager` (or similar).

The logfile should not contain sensitive information, but you might
want to check on that before sending (depending on what you perceive
as
"sensitive").


It could be an NM issue, but it also looks like it might be an nm
-openvpn issue where it doesn't propertly kill the running openvpn
instance when it's been told to stop the connection.  Note there's only
one nm-openvpn-service in in Adrian's output, but multiple openvpn
daemons.

Adrian; do you see "Terminated openvpn daemon with PID %d." anywhere in
your system logs?  One thing you can do to further debug nm-openvpn is:

1) killall -TERM nm-openvpn-service
2) nm-openvpn-service --debug --persist
3) try to reproduce the problem; you'll get a ton of spew from nm
-openvpn-service

Dan
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]