Imported Upstream version 0.9.4.0upstream/0.9.4.0

1 files changed, 24 insertions, 157 deletions

diff --git a/TODO b/TODO
index 3b8438acf..2348b3c62 100644
--- a/TODO
+++ b/TODO
@@ -1,16 +1,30 @@
 So you're interested in hacking on NetworkManager?  Here's some cool
 stuff you could do...
 
-* Internet Connectivity Detection
-
-This feature would consist of attempting to make an HTTP request to a known
-DNS address and compare the response to a well-known string, like Windows does.
-This feature and the server address should be configurable via an option in the
-/etc/NetworkManager/NetworkManager.conf config file.
-
-Once the device has successfully gotten an IPv4 or IPv6 address, it should
-enter the state NM_DEVICE_STATE_IP_CHECK, where this HTTP request would be
-performed.  After the check was done, the device would set a property in
+* Internet Connectivity Detection Enhancements
+
+Current connectivity checking is global, while what we really want is to check
+connectivity per-interface and update the global state based on the composite
+of each device's state.  Unfortunately that requires two things:
+
+1) latest libsoup and glib for using libsoup connection state signals, which
+   allow us to set socket options before the actual connection is made; here
+   we'd bind the socket to the specific IP address of the interface we're
+   using, and possibly set SO_BINDTODEVICE as well
+2) setting /proc/sys/net/ipv4/conf/<iface>/rp_filter to "2" which tells the
+   kernel to route the incoming and outgoing packet properly even though the
+   interface may not have the necessary routes
+
+The first is the largest obstacle, but ideally we implement this and enable it
+when we have the required glib and libsoup versions available.  One other
+complication is that this checking should be done during the
+NM_DEVICE_STATE_IP_CHECK phase (along with other operations like WiFi hotspot
+auto-login) while the current checks are done globally in nm-manager.c, so 
+keeping both code paths might be complex.
+
+But ideally, once the device has successfully gotten an IPv4 or IPv6 address, it
+should enter the state NM_DEVICE_STATE_IP_CHECK, where a connectivity check is
+started.  After the check returns, the device would set a property in
 NMDevicePrivate to indicate whether Internet access was successful or not, and
 advance to the NM_DEVICE_STATE_ACTIVATED state.
 
@@ -19,10 +33,6 @@ nm_manager_update_state() function, would query this property and set
 NM_STATE_CONNECTED_LOCAL, NM_STATE_CONNECTED_SITE, or NM_STATE_CONNECTED_GLOBAL
 based on it and the device's state.
 
-Ideally this feature would not require linking to an HTTP library like libcurl,
-but would use open-coded simple HTTP or libsoup for the request.  The request
-must be done asynchronously, of course.
-
 
 * ADSL support
 
@@ -41,24 +51,6 @@ attribute from the sysfs directory for the ATM interface on 2.6.38.8 and later
 kernels).
 
 
-* Convert WEXT code to nl80211
-
-There's still some WEXT code in NetworkManager for signal strength reporting,
-mode, frequency, BSSID, etc.  This should all get converted to nl80211 code,
-possibly using libnl as a base.  It's not particularly hard, but some
-investigation on how to talk to netlink and how to use nl80211 and netlink
-attributes will need to be done.  Tools like 'iw' already do much of this work,
-but we *cannot* copy & paste code from them since the 'iw' license is not
-compatible with NetworkManager's GPL license.  For exmaple, the following code
-does the job, but should be reworked a bit to use the internal synchronous
-netlink connection from src/nm-netlink-manager.c instead of doing the
-netlink communication on its own with genl_connect() and such:
-
-http://mail.gnome.org/archives/networkmanager-list/2009-September/msg00214.html
-
-The same approach should be taken for signal strength reporting, etc.
-
-
 * Real Access Point mode support
 
 Now that NetworkManager requires wpa_supplicant 0.7.x or later, we can add
@@ -440,63 +432,6 @@ that handle different system proxy handlers.  Some of the proxy handlers are:
   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
-
-
 * Better Tablet/Mobile Behavior
 
 There are a few components to this:
@@ -547,71 +482,3 @@ 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
 are different (ie, for Mobile Hotspot 3G > WiFi).
-
-
-* IP over Infiniband (IPoIB)
-
-These interfaces are similar to Ethernet interfaces with a few distinct
-differences:
-
-  1) they have 64-bit MAC addresses (GUIDs in Infiniband parlance)
-  2) DHCP clients need to be modified to handle IPoIB
-  3) they have a different ARP type and different L2 options
-
-By default the interfaces do not have IP capability, but they gain that
-capability when certain kernel modules (ib_ipoib.ko) are loaded, which causes
-the IP-capable interface is created.  The IP-capable interfaces apparently have
-ARPHRD_INFINIBAND set, which is likely what NM should use to identify them.
-
-One outstanding question is whether NM should (a) detect all Infiniband
-interfaces and load ib_ipoib.ko only when there is a defined NMConnection for
-an Infiniband interface, or (b) whether NM should automatically load ib_ipoib.ko
-for every Infiniband interface, or (c) whether NM should only manage Infiniband
-interfaces that already have associated IP-capable interfaces (ie, something
-else is responsible for loading ib_ipoib.ko).  Depending on our implementation,
-(a) might not be possible, because if IPoIB connections are treated similar to
-plain Ethernet connections, we may not have any information about whether a
-specific NMConnection is Infiniband other than the MAC address.
-
-It turns out that on some distros other components (like system services) may
-load ib_ipoib.ko for us.  For exmaple, the 'rdma' package on Fedora/RHEL systems
-contains /etc/rc.d/init.d/rdma which uses values in /etc/rdma/rdma.conf to load
-ib_ipoib.ko at system startup if the user has requested it via IPOIB_LOAD=yes.
-For the time being, if the some other component of the system loads IP for us,
-NetworkManager should probably still recognize the Infiniband interface, but
-leave it in unmanaged mode if there is no available IPoIB interface associated
-with the Infiniband one.  i.e. for now, NM should not automatically load
-ib_ipoib.ko.
-
-The second question is whether to fold IPoIB support into the NMDeviceEthernet
-class as was done for s390 network interfaces, or whether to create a subclass
-of NMDevice:
-
-1) extend NMDeviceEthernet: this would involve loosening the assumption that
-hardware addresses (the 'hw-address'/'perm-hw-address' properties of
-NMDeviceEthernet and the 'mac-address'/'cloned-mac-address' properties of
-NMSettingWired) are 48 bits wide and instead can be either 48 or 64 bits wide.
-
-2) create a new NMDevice subclass for Infiniband devices tailored to Infiniband
-specific behavior and attributes.  This would be a lot more code since we'd have
-to duplicate much of what NMDeviceEthernet already does, plus add the
-Infiniband device class to libnm-glib.  This also would be the least invasive
-from an API standpoint since the existing API would be unchanged, except for
-the addition of a new value in the NMDeviceType enum, which clients should
-ignore if they don't understand it.  (Need to coordinate additions to this enum
-between 0.8.x and 0.9.x since 0.9.x has more device types, but we want to make
-sure new device types get the same number for both branches).
-
-For Infiniband specific options we could either fold them into NMSettingEthernet
-or create a new NMSettingInfiniband class.  Current Infiniband specific options
-are partitions/P_Keys, datagram vs. connected mode, and MTU.  The default MTU
-varies with the 'mode'; for datagram it is currently 2044, while for connected
-mode it is currently 65520.  Given that we only have 2 IB-specific options
-we should probably just fold them into NMSettingEthernet similar to what was
-done for s390-specific options.
-
-For some general (and also Red Hat/Fedora specific) information see:
-
-http://tools.ietf.org/html/rfc4392
-http://rhkernel.org/#RHEL6+2.6.32-71.18.2.el6/Documentation/infiniband/ipoib.txt
-