Imported Upstream version 0.9.0upstream/0.9.0

1 files changed, 133 insertions, 21 deletions

diff --git a/TODO b/TODO
index 1904f04d3..369be1e56 100644
--- a/TODO
+++ b/TODO
@@ -34,27 +34,11 @@ about ADSL configuration on Linux in general is here:
 
 http://atm.eagle-usb.org/wakka.php?wiki=UeagleAtmDoc
 
-hicham started code for the configuration settings here:
-
-https://github.com/hicham-haouari/NetworkManager-ADSL-Support/commits/adsl
-
-After the libnm-util pieces, internally NM needs to be modified for ADSL
-support, of course.  That involves adding a new NM_DEVICE_TYPE_ADSL in
-NetworkManager.h, and then creating a new NMDeviceAdsl subclass in src/.  It's
-probably easiest to copy the nm-device-ethernet.c file and strip out stuff
-that's not required.  Like the nm-device-ethernet.c file handles the 'carrier'
-state though, the ADSL code should periodically poll the sysfs 'carrier'
-attribute of the DSL modem to detect when the modem has a link with the remote
-DSL concentrator, and only activate connections when the link is present.
-
-Detection of ADSL modems should be handled in nm-udev-manager.c checking for
-the "atm" subsystem.
-
-Code to manage br2684ctl will likely be required to be written for the PPPoE
-case before PPPoE is started on the bridge-created link "nasX".  There are
-quite a few examples of daemon management code in NetworkManager (dnsmasq,
-avahi-autoipd, ppp, dhclient, etc) so there should be a lot of code to
-copy and paste from.
+Big thanks to Pantelis Koukousoulas for getting ADSL working for PPPoA and PPPoE
+methods in the 'adsl' branch in NetworkManager git.  We need more testing, IPv6
+PPP support, and also support for multiple ADSL devices (by reading the "atmindex"
+attribute from the sysfs directory for the ATM interface on 2.6.38.8 and later
+kernels).
 
 
 * Convert WEXT code to nl80211
@@ -132,6 +116,38 @@ against the last scan timestamp, and if the last scan was 10 seconds or more
 ago, a new scan should be requested.
 
 
+* Reconnect to WiFi Networks Only If They Succeeded Once
+
+Currently, NetworkManager will attempt to connect to a previously attempted
+WiFi network even if that network was never successfully connected to.  This
+causes confusion because sometimes users will randomly try various WiFi networks
+hoping to find an open AP, and then wonder why NM tries to reconnect to any of
+those APs later when none of them worked originally due to AP-side MAC filtering
+or other failures.  What should happen is that NetworkManager should set a flag
+on a connection when that connection is successfully connected at least once,
+and only autoconnect the wifi network if that flag is present *and* the
+NMSettingConnection's 'autoconnect' property is TRUE.
+
+This is a bit tricky because we want to consider all connections that don't have
+this flag as having succeeded so that we don't break users' existing connections,
+while holding all newly created connections to this policy.  This flag should
+be determined and set for all connections, even if we only use it to determine
+WiFi behavior for now.
+
+This flag should be a new gboolean property on the NMSettingConnection object
+called "connect-success", with a default value of TRUE.  It should default to
+TRUE to ensure that existing connections are assumed to have connected
+successfully in the past.  New connections created via the AddConnection and
+AddAndActivateConnection D-Bus method calls should have the 'connect-success'
+property explicitly set to FALSE.  Then, in nm-device.c's device_state_changed()
+function where the NM_DEVICE_STATE_ACTIVATED state is handled, the
+'connect-success' property should be set to TRUE.
+
+For WiFi then, in nm-device-wifi.c's get_best_auto_connection() method, the
+'connect-success' property should be checked and if it is FALSE, the connection
+is not considered for auto-activation.
+
+
 * Implement NM_DEVICE_STATE_DISCONNECTING
 
 To allow for "pre-down" scenarios, this state should be implemented before a
@@ -146,6 +162,64 @@ amount of time for each script to complete before allowing the device to
 proceed to the NM_DEVICE_STATE_DISCONNECTED state, fully implementing pre-down.
 
 
+* Ethernet Network Auto-detection
+
+There are various methods we can use to autodetect which wired network connection
+to use if the user connects to more than one wired network on a frequent basis.
+First, 802.1x enterprise switches broadcast frames which can be used to indicate
+that the switch supports 802.1x and thus allow NetworkManager to select an
+802.1x connection instead of blindly trying DHCP.  Second, NetworkManager could
+listen for traffic from a list of MAC addresses.  Third, NetworkManager could
+integrate 'arping' functionality to determine if a given IP address matches a
+given MAC address, and thus automatically select that connection.  All these
+methods can co-exist and be used in parallel.
+
+One small caveat is that MAC addresses are trivial to spoof, so just because
+NetworkManager has discovered a certain MAC address does not mean the network
+is authenticated; only 802.1x security can assure that a network is the network
+the user expects it to be.
+
+In any case, a new 'anchor-addresses' property of type string-array should be
+added to the NMSettingWired setting.  Each string element of this property
+should be of the format "<ip>/<mac>" or simply "<mac>".  The first format with
+an IP address would indicate that "arping"-type behavior should be used to
+actively detect the given MAC address; obviously if the given MAC address is
+used for passive discovery as well.  The second format simply lists a MAC
+address to passively listen for.
+
+One drawback of listening or probing for known MAC addresses is an increase in
+latency during connections to ethernet networks.  The probing/listening delay
+should be a reasonable amount of time, like 4 - 5 seconds or so, and should
+only be used when a visible connection has anchor addresses.
+
+Next a gboolean 'anchor-probing' variable should be added to the
+NMDeviceEthernetPrivate structure in src/nm-device-ethernet.c.  This variable
+should be set to TRUE whenever the device's carrier turns on *and* there are
+visible NMConnections with anchor addresses (ie, connections which are system-
+wide or where one of the allowed users of that connection is logged in).  Then
+probing and listening are started, which involves opening a low-level socket
+on the interface and starting the arping run or listening for MAC addresses.
+A timer is also started (don't forget to cache the timer's source ID in the
+NMDeviceEthernetPrivate data, and to cancel the timer whenever the device
+transitions to any state other than DISCONNECTED).
+
+If a known MAC address is discovered as a result of probing or listening, the
+probe/listen socket, timeout, and data are cleaned up, and NetworkManager
+would begin activation of the NMConnection that specified the found MAC address
+in the 'anchor-addresses' property.  If two or more connections specify the
+same MAC address, the connection with the most recent timestamp should be
+preferred.
+
+Similarly, if the probing/listening process detects 802.1x frames the device
+should be marked as requring 802.1x authentication until the carrier drops.
+This would be accomplished by adding a new property to the NMDeviceEthernet
+object and exporting that property through the
+introspection/nm-device-ethernet.xml file.  This would allow clients like
+applets to ensure that users are aware that the device will not allow
+un-authenticated connections and that additional credentials are required to
+successfully connect to this network.
+
+
 * VPN re-connect
 
 NM should remember whether a VPN was connected if a connection disconnects
@@ -230,6 +304,44 @@ 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).
 
 
+* VPN Service Daemon Secret Requests
+
+In addition to NM asking the service daemons whether more secrets are required,
+VPN service daemons (like nm-vpnc-service, nm-openvpn-service, etc) should be
+able to ask NetworkManager to provide secrets during the connection attempt. To
+do this, the plugin should advertise its ability to handle out-of-band secrets
+in its .service file via the key 'async-secrets=true'.  NetworkManager would
+check that key and if present activate the VPN as normal, but skip the explicit
+NeedSecrets calls.
+
+Instead, a new "SecretsRequired" signal would be added to
+introspection/nm-vpn-plugin.xml (and corresponding helper code added to
+libnm-glib/nm-vpn-plugin.c) that would be emitted when the plugin determined
+that secrets were required.  This signal would have D-Bus signature of "sas"
+for the arguments [ <s:uuid>, <as:secrets> ] with the <uuid> obviously being
+the connection UUID, and <secrets> being an array of strings of plugin-specific
+strings the plugin requires secrets for.  This array of strings would then be
+passed as the "hints" parameter in nm-vpn-connection.c when secrets are
+requested from agents in a subsequent nm_settings_connection_get_secrets() call.
+At this time the agent code only allows one hint per request, so we may need to
+extend that to allow more than one hint.
+
+Thus when connecting if the plugin supported async secrets NetworkManager would
+still request existing secrets (without interactivity) and send them to the
+VPN service daemon in the Connect D-Bus method, then wait for the service daemon
+to either request secrets asynchronously via the SecretsRequired signal or to
+signal successful connection via the Ip4Config signal.
+
+The vpnc plugin would need to be reworked to open a pipe to vpnc's stdout and
+stdin file descriptors to capture any authentication messages, and to match
+these messages to known secrets request strings.  When receiving one of these
+strings the plugin would determine which secret was being requested and then
+emit the SecretsRequired signal to NetworkManager.  This would also imply that
+nm-vpnc-service exectutes vpnc with the "--xauth-inter" argument to enable
+challenge-response and does not use the "--non-inter" flag which suppresses that
+behavior.
+
+
 * WPS
 
 wpa_supplicant has support for WPS (Wifi Protected Setup, basically Bluetooth-