Imported Upstream version 0.8.9997upstream/0.8.9997

1 files changed, 149 insertions, 9 deletions

diff --git a/TODO b/TODO
index 6afd7f98f..1904f04d3 100644
--- a/TODO
+++ b/TODO
@@ -88,6 +88,11 @@ are still missing.  If the wifi driver supports AP mode, then in
 src/supplicant-manager/ NM should send an AP-mode config instead of sending
 the adhoc config.
 
+Note that some devices (airo, ipw2100, ipw2200, iwl3945, iwl4965, atmel, zd1201)
+will never support AP mode due to firmware limitations, so we clearly must still
+provide Ad-Hoc connection sharing support for those devices and switch between
+Ad-Hoc and AP mode depending on device capabilities.
+
 
 * On-Demand WiFi Scan support
 
@@ -189,15 +194,40 @@ signals.  A patch here:
 
 http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=vpn-ip-method
 
-shows that, but internally NM needs to process this request, and instead of
-applying given IPv4 or IPv6 configuration (since there isn't any yet) it should
-kick off a DHCP request and wait for the request to finish.  When it does
-finish it should apply the configuration to the interface.  Most of the DHCP
-code is already written, but src/vpn-manager/nm-vpn-connection.c would need
-updates to recognize the new "method" property of the IP4Config signal and
-handle the DHCP lifetime after that.  The base NMDevice class in nm-device.c
-has code for handling the DHCP lifetime, connecting to NMDHCPManager signals
-for renew and failure processing, etc, and could be used as an example.
+shows that.  In nm-vpn-connection.c, upon receipt of the D-Bus Ip4Config signal
+from the VPN plugin, NetworkManager would inspect the "method" property of the
+ip4 config dictionary.  If that property was present and set to "auto" then
+DHCP would be started using the network interface returned in the dict.  The
+nm_vpn_connection_ip4_config_get() function should be split up into two
+functions, one containing the existing code for static configuration, and a
+second for handling DHCP kickoff.  Minimal parsing of the response should be
+handled in the newly reduced nm_vpn_connection_ip4_config_get() function.
+
+To handle DHCP, the NMVPNConnectionPrivate structure should have two members
+added:
+
+    NMDHCPManager *dhcp_manager;
+    NMDHCPClient  *dhcp4_client;
+
+which would be initialized in the new DHCP handler code split off from
+nm_vpn_connection_ip4_config_get().  These new members would be disposed of in
+both vpn_cleanup() and dispose(), though remember to stop any ongoing DHCP
+transaction when doing so (see dhcp4_cleanup() in nm-device.c for example code).
+For basic code to start the DHCP transaction, see dhcp4_start() in nm-device.c
+as well.  After calling nm_dhcp_manager_start_ip4() and connecting the signals
+to monitor success and failure, the VPN IP4 config handler would simply return
+without changing VPN state, unless a failure occurred.
+
+Then, when the DHCP transaction succeeds, which we'd know by checking the
+DHCP client state changes in the "state-changed" signal handler we attached to
+the DHCP client object returned from nm_dhcp_manager_start_ip4(), the code
+would retrieve the completed NMIP4Config object from the DHCP client using the
+nm_dhcp_client_get_ip4_config() function, and then proceed to execute
+essentially the bottom-half of the existing nm_vpn_connection_ip4_config_get()
+function to merge that config with user overrides and apply it to the VPN
+tunnel interface.  Other state changes from the DHCP client might trigger a
+failure of the VPN connection, just like DHCP timeouts and lease-renewal
+failures do for other devices (see dhcp_state_changed() in nm-device.c).
 
 
 * WPS
@@ -243,3 +273,113 @@ association using WPS, since quite a few routers out there are broken, or
 because the user has no physical access to the router itself, but has been given
 as passphrase/PSK instead.
 
+
+* Proxies
+
+HTTP and other proxies are per-connection configuration.  It's highly unlikely
+that the same proxy you need to use at work is used at home or in a coffee shop.
+Thus, it makes sense that which proxy settings to use should be updated when
+network connections change.  NetworkManager is a perfect place to do this since
+it tracks which network connections are active, and it already queries the
+network for automatic proxy configuration via DHCP and WPAD.
+
+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
+various desktop environment proxy configuration tools like the GNOME Network
+Proxy control panel; this should include at a minimum:
+
+  method: "auto", "manual", "none"
+  default-proxy: string
+  default-proxy-port: uint
+  default-always: boolean (use default proxy for all protocols)
+  ssl-proxy: string
+  ssl-proxy-port: uint
+  ftp-proxy: string
+  ftp-proxy-port: uint
+  socks-proxy: string
+  socks-proxy-port: uint
+  socks-version: uint, either 4 or 5
+  no-proxy-for: array of strings (things not to use the proxy for, ie ".foobar.com",
+                 "192.168.0.1/24", an IPv6 address, etc)
+  pac-url: string (URL of PAC file, overrides DHCP-provided WPAD value)
+  (FIXME: proxy authentication?  do we need separate user/pass properties for
+    each protocol type?  should NM handle proxy auth or should it be punted
+    to each application?)
+
+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.
+
+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:
+
+  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?
+
+
+* Bridging and Bonding Support
+
+The largest complication here is that NetworkManager normally operates on
+physical interfaces, while bridging and bonding involve tying multiple physical
+interfaces together into a logical interface.  This has interesting implications
+for the D-Bus API and the NM device model.  The first complication is that
+we may need to do 802.1x port authentication on an interface before it can
+communicate with the other side of the link, and those credentials may be
+different for each interface; thus we may need to do separate 802.1x
+operations on each interface that is part of a bridge/bond before adding each
+one to the master bridge/bond interface.
+
+In this way bridge/bond interfaces may be treated the same way as NetworkManager
+treats VPN interfaces already; one or more physical interface NMConnections must
+be activated before the master bridge/bond interface's NMConnection can be
+activated, though this all happens internally.
+
+To enable bridging and bonding in the NMConnection itself, we should create
+new NMSettingBridge and NMSettingBond classes that contain information specific
+to each.  Both settings would contain a 'components' property with an
+'array of string' type which would contain the UUIDs of the Connections of
+physical interfaces that compose the bridge or bond.  Thus NetworkManager would
+have the necessary information to tie lower-level interface configuration
+(802.1x, MTU, MAC address locking, duplex mode, speed, etc) to each physical
+interface that will be part of the bridge/bond, configure the interface with
+it, and then configure the master bridge/bond interface at upper layers using
+configuration specific for the bridge/bond interface (like IP details).  Thus
+for a single active bridge, two or more NMConnections would be activated; one
+for each physical interface component of the bridge/bond, and one for the master
+bridge/bond interface itself.
+
+NMSettingBridge would contain at least the following keys:
+
+  components: (array of string) UUIDs of component connections
+  stp:        (boolean) on to enable STP, off to disable
+
+NMSettingBond would contain at least the following keys:
+
+  components: (array of string) UUIDs of component connections
+  mode:       (string) one of "balance-rr", "active-backup", "balance-xor",
+                  "broadcast", "802.3ad", "balance-tlb", or "balance-alb"
+  monitor-interval: (uint) Specifies link monitoring interval (in milliseconds);
+                       NM will always enable netlink carrier monitoring if this
+                       value is non-zero so this property only affects speed and
+                       duplex checking
+
+In the future we may consider adding other bonding parameters like "up-delay"
+and "down-delay".
+
+Then we'd add a 'component' (boolean) property to NMSettingConnection to
+indicate that the component interface connections were in fact components of
+a bridge or bond and shouldn't be automatically started by NetworkManager or
+displayed as separate connections in the user interface.
+
+TO BE CONTINUED