OpenVPN connection configured via GUI does not remove the tunnel interface when done
Reported by
j...@voxilate.com,
Apr 1 2017
|
||||||||
Issue descriptionChrome Version: 57.0.2987.137 Chrome OS Version: 9202.60 Chrome OS Platform: Acer Chromebook 11 Network info: N/A Please specify Cr-* of the system to which this bug/feature applies (add the label below). Steps To Reproduce: (1) chrome://net-internals/#chromeos > Import ONC File > Wifi icon > VPN disconnected > choose connection > Connect. (2) Disconnect. (3) Repeat steps 1 and 2. (4) crosh > shell > ifconfig Expected Result: The tunnel interface should be fully brought down. wlan and loopback interfaces should be all we see. Actual Result: shill appears to be appropriately unbinding from wlan0 and clearing routes, but not bringing the interface down, so each new OpenVPN connect (from the interface) creates a new tunX. How frequently does this problem reproduce? (Always, sometimes, hard to reproduce?) Always (with my current config; have not tested with other VPNs). Also, this is from the UI/invoking shill. OpenVPN from the console removes tun interfaces appropriately. What is the impact to the user, and is there a workaround? If so, what is it? Likely minor - users wouldn't notice until/unless wonky behavior could ensue after these build up on a system that never gets rebooted...could be worth an automated test case? ;)
,
Apr 6 2017
,
Apr 6 2017
,
Apr 7 2017
,
May 2 2017
The following revision refers to this bug: https://chromium.googlesource.com/aosp/platform/system/connectivity/shill/+/7c3204dc644deda4e3ee661e1ab9fb9ea541d24c commit 7c3204dc644deda4e3ee661e1ab9fb9ea541d24c Author: Kevin Cernekee <cernekee@chromium.org> Date: Tue May 02 02:18:12 2017 shill: OpenVPNDriver: Fix deletion of tunnel interfaces during cleanup shill used to have a ProcessKiller class, which was used to invoke a callback when the external openvpn process was killed. This callback cleanly removed the tunnel interface. But later ProcessKiller was removed in favor of ProcessManager. Commit 609e2f164a71c1 ("shill: OpenVPNDriver: remove use of ProcessKiller") converted OpenVPNDriver to use the new ProcessManager interface, but unlike ProcessKiller, ProcessManager will not invoke callbacks for a watched process after OpenVPNDriver has requested termination. So, per the documentation in process_manager.h for StopProcess(), this will schedule a callback that never gets run: process_manager_->UpdateExitCallback(pid_, callback); process_manager_->StopProcess(pid_); Consequently, users report that the tunX interfaces are never deleted, and a bunch of old unused tunX interfaces "pile up" over time as the user connects and disconnects from the VPN. To work around this, terminate the openvpn daemon synchronously, then delete the tunX interface without a callback. (In my testing openvpn seems to exit immediately upon receiving SIGTERM, so it generally should not block shill.) BUG= chromium:707518 TEST=manually connect/disconnect from an openvpn server, then run `ifconfig` to verify that the tunX interface is gone TEST=manually connect to an openvpn server, then `killall -SEGV openvpn` and verify that the tunX interface is gone TEST=unit tests Change-Id: I428ad68e2bcfa9f6260ca954a836b05bb64aa51c Reviewed-on: https://chromium-review.googlesource.com/490524 Commit-Ready: Kevin Cernekee <cernekee@chromium.org> Tested-by: Kevin Cernekee <cernekee@chromium.org> Reviewed-by: Ben Chan <benchan@chromium.org> [modify] https://crrev.com/7c3204dc644deda4e3ee661e1ab9fb9ea541d24c/vpn/openvpn_driver.h [modify] https://crrev.com/7c3204dc644deda4e3ee661e1ab9fb9ea541d24c/vpn/openvpn_driver.cc [modify] https://crrev.com/7c3204dc644deda4e3ee661e1ab9fb9ea541d24c/vpn/openvpn_driver_unittest.cc
,
May 2 2017
,
Aug 1 2017
,
Jan 22 2018
,
Aug 14
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by svaldez@chromium.org
, Apr 3 2017