Imported Upstream version 0.8.998upstream/0.8.998

1 files changed, 244 insertions, 0 deletions

diff --git a/TODO b/TODO
index 8b1378917..6afd7f98f 100644
--- a/TODO
+++ b/TODO
@@ -1 +1,245 @@
+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
+NMDevicePrivate to indicate whether Internet access was successful or not, and
+advance to the NM_DEVICE_STATE_ACTIVATED state.
+
+The NMManager object, when determining the overall NM_STATE_* state in the
+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
+
+NetworkManager should natively support ADSL modems using one of the 3 main
+connection methods, PPP over ATM (pppoa), PPP over Ethernet (pppoe), or
+IP over ATM (ipoatm).  Initial support could be targeted at just pppoa and
+pppoe, and there is some code in NetworkManager already for pppoe.  More info
+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.
+
+
+* 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
+full Access Point (AP) mode support.  NetworkManager currently implements
+connection sharing via AdHoc mode support, which has some limitations.  Instead,
+we should check whether the wifi device supports AP mode, and if so, use
+that mode instead.  wpa_supplicant has support for a "lightweight AP" mode which
+we should use.  Witold Sowa started this support a while ago and wrote the new
+D-Bus API for wpa_supplicant that makes all this possible, but some NM pieces
+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.
+
+
+* On-Demand WiFi Scan support
+
+Single-user and embedded devices often use a continuous wifi scan when the
+networking configuration interface is open to quickly allow users to find their
+wifi network.  NM periodically scans, but this could take as long as 2 mintues
+to update the list.  Note that WiFi scans require 2 - 10 seconds to complete,
+and during this time normal traffic (video, VOIP, streaming music, downloads,
+etc) is not transmitted, so a WiFi scan is a disruptive operation to the user.
+
+A D-Bus method should be added to the NMDeviceWifi device to allow user
+applications to request a scan.  This request should be rate-limited to no
+more than once every 10 seconds to give time for traffic to resume when the
+scan is done, and to lessen the effect of any DDoS by malicious user
+applications.  This request should also be restricted by one or more PolicyKit
+permissions like org.freedesktop.NetworkManager.network-control.
+
+To begin, a new method definition should be added to the
+introspection/nm-device-wifi.xml for a method called "RequestScan" which takes
+an argument called "options" of type of "a{sv}".  This argument will be used
+later.  An annotation (like the other functions have) should be added so that
+the method will be called "impl_device_request_scan".
+
+Next, the corresponding method implementation should be added to
+src/nm-device-wifi.c by adding the prototype for impl_device_request_scan
+near the top of the file, and implementing it below.  The implementation will
+recieve a GHashTable corresponding to the "a{sv}" argument list from the XML
+file, but we can ignore that for now.
+
+The incoming request should be authenticated using nm_auth_get_caller_uid()
+and additionally starting a PolicyKit authentication check with
+with nm_auth_chain_new().  See the function manager_device_disconnect_request()
+in src/nm-manager.c for an example of this.
+
+Only after the caller is authorized to scan should the request be checked
+against the last scan timestamp, and if the last scan was 10 seconds or more
+ago, a new scan should be requested.
+
+
+* Implement NM_DEVICE_STATE_DISCONNECTING
+
+To allow for "pre-down" scenarios, this state should be implemented before a
+device is taken down while it still has connectivity.  If the device is
+taken down because it's ethernet carrier was dropped, or because the WiFi
+connection was terminated by the supplicant, this state is pointless and should
+be skipped.  But if the user requested a manual "disconnect", or NM is dropping
+connections on exit, etc, then this state should be entered.  In the future
+this state should hook into a new dispatcher action in src/NetworkManagerUtils.c
+to exectue dispatcher scripts during the disconnection, and to wait a limited
+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.
+
+
+* VPN re-connect
+
+NM should remember whether a VPN was connected if a connection disconnects
+(like WiFi drops out or short carrier drop) or if the laptop goes to sleep.
+Upon reconnect, if the same Connection is again active, the previously
+connected VPN should be activated again as well.  Basically, don't just drop
+the VPN because WiFi choked for 10 seconds, but reconnect the VPN if it was
+connected before the drop.
+
+
+* VPN autoconnect
+
+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
+pseudo-ethernet device to obtain addressing information.  This is not currently
+possible, but NM already has all the code for DHCP.  Thus, a new "method"
+key should be defined in include/NetworkManagerVPN.h to allow for DHCP to
+be performed if the VPN service daemon requests it in the IP4Config or IP6Config
+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.
+
+
+* WPS
+
+wpa_supplicant has support for WPS (Wifi Protected Setup, basically Bluetooth-
+like PIN codes for setting up a wifi connection) and we should add support for
+this to NetworkManager too.  APs that support WPS will say so in their beacon
+IEs which are contained in the "WPA" and "RSN" properties of the BSS object
+exported by the supplicant, and can be processed in src/nm-wifi-ap.c's
+foreach_property_cb() function.  We should add some private fields to the
+NMAccessPoint object (defined in nm-wifi-ap.c) to remember whether a specific
+AP supports WPS and what WPS methods it supports, and expose that over D-Bus to
+GUI clients as well.
+
+There are two common WPS setup methods: PIN and button.  For PIN, the router
+either displays a random PIN on an LCD or the router's web UI, or a static PIN
+is printed on the router itself.  The user enters that PIN instead of a PSK
+when connecting.  For the "button" method, the router has a physical button that
+when pushed, allows any client to connect for a short period of time.
+
+We'll then need to add some properties to the NMSettingWirelessSecurity setting
+for the WPS PIN code so that when the user enters it through the GUI, it can
+be passed back to NM.  And we'll need to figure out some mechanism for passing
+back an indication that the user pushed the button on the router for the
+pushbutton method.
+
+When connecting to a new access point that supports WPS, the GUI client would
+call the AddAndActivateConnection method and wait for NM to request secrets.
+NM would determine that the AP supports WPS, and request WPS secrets from the
+applet.  The applet would ask the user for a PIN, or to push the button on the
+AP, instead of asking for a passphrase or PSK.  When the user has entered the
+PIN or pushed the button, the applet returns this information to NM, which
+proceeds with the connection.
+
+NM sends the correct wpa_supplicant config for WPS to the supplicant, and waits
+for the connection to occur.  WPS can only be used the *first* time, so after a
+first successfull connection, NM must request the actual hexadecimal PSK from 
+wpa_supplicant via D-Bus, and store that PSK in the connection, clear any WPS
+PIN code from the connection, and save the connection to backing storage.
+
+Any applet GUI should also allow the user to enter the PSK instead of completing
+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.