connected before the drop.
-* VPN autoconnect (bgo #560471)
-
-We should add a property to the NMSettingConnection object in
-libnm-util/nm-setting-connection.c called "vpns" that is a string list,
-containing a list of Connection UUIDs that should be activated when the base
-connection itself is activated. This will allow a VPN connection to be
-started every time another connection is started, so that if you choose you're
-always on the VPN in your favorite coffee shop.
-
-The NM_DEVICE_STATE_SECONDARIES state was added specifically for cases like
-this. Thus, after the base device has IP connectivity, but before it has
-signaled that it's fully activated, the device should enter the SECONDARIES
-state and kick off activation of the given VPN connection. Only after this
-VPN connection has successfully connected should the base device to the
-NM_DEVICE_STATE_ACTIVATED state.
-
-
-* VPN and IPv6
-
-The internal VPN capability should support IPv6. Essentially, the D-Bus
-interface between NetworkManager and the VPN service daemons should be extended
-with an IP6Config signal that passes up the IPv6 addressing and routing details
-if the VPN daemon is IPv6 capable. NM should then process those details like it
-does with IPv4. include/NetworkManagerVPN.h should be updated with key/value
-pairs defining the various IPv6 attributes much like the IPv4 ones are defined.
-
-
* VPN IP Methods
Some VPNs (openvpn with TAP for example) require that DHCP is run on a
it tracks which network connections are active, and it already queries the
network for automatic proxy configuration via DHCP and WPAD.
+However, proxy handling is complicated and may require use of Javascript to
+parse PAC files provided by WPAD, and this is not something NetworkManager
+should do itself. Instead, that should be left to "proxy handlers", or external
+utilities like libproxy or pacrunner that take raw proxy information, parse it,
+and tell applications what proxy server to use for a specific network resource.
+NetworkManager should provide all the proxy information it can find to these
+external proxy handlers via the D-Bus interface and dispatcher scripts.
+
We should add a new NMSetting subclass called NMSettingProxy that holds
necessary proxy configuration. The properties of this setting should be a
superset of what is provided in the Firefox proxy configuration screen and the
After completing IP configuration but still during the NM_DEVICE_STATE_IP_CONFIG
activation stage, NetworkManager would merge the automatically supplied proxy
configuration (from DHCP's WPAD option) with user-provided overrides from the
-NMSettingProxy and send the results to the system. The 'default' connection's
-proxy configuration would be preferred, so we'd have to update proxy
-configuration from nm-policy.c the same time we update DNS information and the
-default route.
+NMSettingProxy export the resulting proxy configuration via D-Bus and dispatcher
+scripts. The 'default' connection's proxy configuration would be preferred, so
+we'd have to update proxy configuration from nm-policy.c the same time we update
+DNS information and the default route.
-The merged proxy configuration would then be sent to the system. There is no
-canonical proxy daemon in-use, so we should have plugins (if not separate
-shared libraries, then certainly encapsulated source files that implement a
-common glib GInterface or are subclasses of eg a parent NMProxyHandler class)
-that handle different system proxy handlers. Some of the proxy handlers are:
+Merged proxy information should be exposed in two places. First, it should be
+exported over D-Bus as a property of the org.freedesktop.NetworkManager.Device
+interface. This property should be named "ProxyInfo" and should have the
+D-Bus signature "a{sv}" (eg, dictionary) and should mirror the properties from
+the NMSettingProxy object.
- libproxy: need to figure out how it gets proxy info and have NM write merged
- proxy config out to that location
- pacrunner: a D-Bus enabled daemon, NM would call D-Bus methods of the
- pacrunner service with the proxy information
- GNOME/KDE: how do these desktop environments retrieve proxy configuration?
+Second, it should be exported via the dispatcher to dispatcher scripts when
+with the "up" and "down" events.
* Better Tablet/Mobile Behavior
the best route to go for desktop use-cases as well. Instead of bringing all
available connections up, only bring up the "best" connection at any given
time based on the current priority list (which is rougly Ethernet > WiFi >
-3G/Bluetooth/WiMAX). However, to ensure seamless connectivity, when one
-connection begins to degrade, the next-best connection should be started before
-the current one is terminated, such that there is a small amount of overlap.
+3G/Bluetooth). However, to ensure seamless connectivity, when one connection
+begins to degrade, the next-best connection should be started before the
+current one is terminated, such that there is a small amount of overlap.
Consequently the same behavior should be used when a better connection becomes
available. This behavior should be suspended when special connections like
Internet Connection Sharing ones are started, where clearly the priorities
projects / NetworkManager.git / blobdiff