TODO

   1 So you're interested in hacking on NetworkManager?  Here's some cool
   2 stuff you could do...
   3
   4 * Internet Connectivity Detection
   5
   6 This feature would consist of attempting to make an HTTP request to a known
   7 DNS address and compare the response to a well-known string, like Windows does.
   8 This feature and the server address should be configurable via an option in the
   9 /etc/NetworkManager/NetworkManager.conf config file.
  10
  11 Once the device has successfully gotten an IPv4 or IPv6 address, it should
  12 enter the state NM_DEVICE_STATE_IP_CHECK, where this HTTP request would be
  13 performed.  After the check was done, the device would set a property in
  14 NMDevicePrivate to indicate whether Internet access was successful or not, and
  15 advance to the NM_DEVICE_STATE_ACTIVATED state.
  16
  17 The NMManager object, when determining the overall NM_STATE_* state in the
  18 nm_manager_update_state() function, would query this property and set
  19 NM_STATE_CONNECTED_LOCAL, NM_STATE_CONNECTED_SITE, or NM_STATE_CONNECTED_GLOBAL
  20 based on it and the device's state.
  21
  22 Ideally this feature would not require linking to an HTTP library like libcurl,
  23 but would use open-coded simple HTTP or libsoup for the request.  The request
  24 must be done asynchronously, of course.
  25
  26
  27 * ADSL support
  28
  29 NetworkManager should natively support ADSL modems using one of the 3 main
  30 connection methods, PPP over ATM (pppoa), PPP over Ethernet (pppoe), or
  31 IP over ATM (ipoatm).  Initial support could be targeted at just pppoa and
  32 pppoe, and there is some code in NetworkManager already for pppoe.  More info
  33 about ADSL configuration on Linux in general is here:
  34
  35 http://atm.eagle-usb.org/wakka.php?wiki=UeagleAtmDoc
  36
  37 hicham started code for the configuration settings here:
  38
  39 https://github.com/hicham-haouari/NetworkManager-ADSL-Support/commits/adsl
  40
  41 After the libnm-util pieces, internally NM needs to be modified for ADSL
  42 support, of course.  That involves adding a new NM_DEVICE_TYPE_ADSL in
  43 NetworkManager.h, and then creating a new NMDeviceAdsl subclass in src/.  It's
  44 probably easiest to copy the nm-device-ethernet.c file and strip out stuff
  45 that's not required.  Like the nm-device-ethernet.c file handles the 'carrier'
  46 state though, the ADSL code should periodically poll the sysfs 'carrier'
  47 attribute of the DSL modem to detect when the modem has a link with the remote
  48 DSL concentrator, and only activate connections when the link is present.
  49
  50 Detection of ADSL modems should be handled in nm-udev-manager.c checking for
  51 the "atm" subsystem.
  52
  53 Code to manage br2684ctl will likely be required to be written for the PPPoE
  54 case before PPPoE is started on the bridge-created link "nasX".  There are
  55 quite a few examples of daemon management code in NetworkManager (dnsmasq,
  56 avahi-autoipd, ppp, dhclient, etc) so there should be a lot of code to
  57 copy and paste from.
  58
  59
  60 * Convert WEXT code to nl80211
  61
  62 There's still some WEXT code in NetworkManager for signal strength reporting,
  63 mode, frequency, BSSID, etc.  This should all get converted to nl80211 code,
  64 possibly using libnl as a base.  It's not particularly hard, but some
  65 investigation on how to talk to netlink and how to use nl80211 and netlink
  66 attributes will need to be done.  Tools like 'iw' already do much of this work,
  67 but we *cannot* copy & paste code from them since the 'iw' license is not
  68 compatible with NetworkManager's GPL license.  For exmaple, the following code
  69 does the job, but should be reworked a bit to use the internal synchronous
  70 netlink connection from src/nm-netlink-manager.c instead of doing the
  71 netlink communication on its own with genl_connect() and such:
  72
  73 http://mail.gnome.org/archives/networkmanager-list/2009-September/msg00214.html
  74
  75 The same approach should be taken for signal strength reporting, etc.
  76
  77
  78 * Real Access Point mode support
  79
  80 Now that NetworkManager requires wpa_supplicant 0.7.x or later, we can add
  81 full Access Point (AP) mode support.  NetworkManager currently implements
  82 connection sharing via AdHoc mode support, which has some limitations.  Instead,
  83 we should check whether the wifi device supports AP mode, and if so, use
  84 that mode instead.  wpa_supplicant has support for a "lightweight AP" mode which
  85 we should use.  Witold Sowa started this support a while ago and wrote the new
  86 D-Bus API for wpa_supplicant that makes all this possible, but some NM pieces
  87 are still missing.  If the wifi driver supports AP mode, then in
  88 src/supplicant-manager/ NM should send an AP-mode config instead of sending
  89 the adhoc config.
  90
  91
  92 * On-Demand WiFi Scan support
  93
  94 Single-user and embedded devices often use a continuous wifi scan when the
  95 networking configuration interface is open to quickly allow users to find their
  96 wifi network.  NM periodically scans, but this could take as long as 2 mintues
  97 to update the list.  Note that WiFi scans require 2 - 10 seconds to complete,
  98 and during this time normal traffic (video, VOIP, streaming music, downloads,
  99 etc) is not transmitted, so a WiFi scan is a disruptive operation to the user.
 100
 101 A D-Bus method should be added to the NMDeviceWifi device to allow user
 102 applications to request a scan.  This request should be rate-limited to no
 103 more than once every 10 seconds to give time for traffic to resume when the
 104 scan is done, and to lessen the effect of any DDoS by malicious user
 105 applications.  This request should also be restricted by one or more PolicyKit
 106 permissions like org.freedesktop.NetworkManager.network-control.
 107
 108 To begin, a new method definition should be added to the
 109 introspection/nm-device-wifi.xml for a method called "RequestScan" which takes
 110 an argument called "options" of type of "a{sv}".  This argument will be used
 111 later.  An annotation (like the other functions have) should be added so that
 112 the method will be called "impl_device_request_scan".
 113
 114 Next, the corresponding method implementation should be added to
 115 src/nm-device-wifi.c by adding the prototype for impl_device_request_scan
 116 near the top of the file, and implementing it below.  The implementation will
 117 recieve a GHashTable corresponding to the "a{sv}" argument list from the XML
 118 file, but we can ignore that for now.
 119
 120 The incoming request should be authenticated using nm_auth_get_caller_uid()
 121 and additionally starting a PolicyKit authentication check with
 122 with nm_auth_chain_new().  See the function manager_device_disconnect_request()
 123 in src/nm-manager.c for an example of this.
 124
 125 Only after the caller is authorized to scan should the request be checked
 126 against the last scan timestamp, and if the last scan was 10 seconds or more
 127 ago, a new scan should be requested.
 128
 129
 130 * Implement NM_DEVICE_STATE_DISCONNECTING
 131
 132 To allow for "pre-down" scenarios, this state should be implemented before a
 133 device is taken down while it still has connectivity.  If the device is
 134 taken down because it's ethernet carrier was dropped, or because the WiFi
 135 connection was terminated by the supplicant, this state is pointless and should
 136 be skipped.  But if the user requested a manual "disconnect", or NM is dropping
 137 connections on exit, etc, then this state should be entered.  In the future
 138 this state should hook into a new dispatcher action in src/NetworkManagerUtils.c
 139 to exectue dispatcher scripts during the disconnection, and to wait a limited
 140 amount of time for each script to complete before allowing the device to
 141 proceed to the NM_DEVICE_STATE_DISCONNECTED state, fully implementing pre-down.
 142
 143
 144 * VPN re-connect
 145
 146 NM should remember whether a VPN was connected if a connection disconnects
 147 (like WiFi drops out or short carrier drop) or if the laptop goes to sleep.
 148 Upon reconnect, if the same Connection is again active, the previously
 149 connected VPN should be activated again as well.  Basically, don't just drop
 150 the VPN because WiFi choked for 10 seconds, but reconnect the VPN if it was
 151 connected before the drop.
 152
 153
 154 * VPN autoconnect
 155
 156 We should add a property to the NMSettingConnection object in
 157 libnm-util/nm-setting-connection.c called "vpns" that is a string list,
 158 containing a list of Connection UUIDs that should be activated when the base
 159 connection itself is activated.  This will allow a VPN connection to be
 160 started every time another connection is started, so that if you choose you're
 161 always on the VPN in your favorite coffee shop.
 162
 163 The NM_DEVICE_STATE_SECONDARIES state was added specifically for cases like
 164 this.  Thus, after the base device has IP connectivity, but before it has
 165 signaled that it's fully activated, the device should enter the SECONDARIES
 166 state and kick off activation of the given VPN connection.  Only after this
 167 VPN connection has successfully connected should the base device to the
 168 NM_DEVICE_STATE_ACTIVATED state.
 169
 170
 171 * VPN and IPv6
 172
 173 The internal VPN capability should support IPv6.  Essentially, the D-Bus
 174 interface between NetworkManager and the VPN service daemons should be extended
 175 with an IP6Config signal that passes up the IPv6 addressing and routing details
 176 if the VPN daemon is IPv6 capable.  NM should then process those details like it
 177 does with IPv4.  include/NetworkManagerVPN.h should be updated with key/value
 178 pairs defining the various IPv6 attributes much like the IPv4 ones are defined.
 179
 180
 181 * VPN IP Methods
 182
 183 Some VPNs (openvpn with TAP for example) require that DHCP is run on a
 184 pseudo-ethernet device to obtain addressing information.  This is not currently
 185 possible, but NM already has all the code for DHCP.  Thus, a new "method"
 186 key should be defined in include/NetworkManagerVPN.h to allow for DHCP to
 187 be performed if the VPN service daemon requests it in the IP4Config or IP6Config
 188 signals.  A patch here:
 189
 190 http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?h=vpn-ip-method
 191
 192 shows that, but internally NM needs to process this request, and instead of
 193 applying given IPv4 or IPv6 configuration (since there isn't any yet) it should
 194 kick off a DHCP request and wait for the request to finish.  When it does
 195 finish it should apply the configuration to the interface.  Most of the DHCP
 196 code is already written, but src/vpn-manager/nm-vpn-connection.c would need
 197 updates to recognize the new "method" property of the IP4Config signal and
 198 handle the DHCP lifetime after that.  The base NMDevice class in nm-device.c
 199 has code for handling the DHCP lifetime, connecting to NMDHCPManager signals
 200 for renew and failure processing, etc, and could be used as an example.
 201
 202
 203 * WPS
 204
 205 wpa_supplicant has support for WPS (Wifi Protected Setup, basically Bluetooth-
 206 like PIN codes for setting up a wifi connection) and we should add support for
 207 this to NetworkManager too.  APs that support WPS will say so in their beacon
 208 IEs which are contained in the "WPA" and "RSN" properties of the BSS object
 209 exported by the supplicant, and can be processed in src/nm-wifi-ap.c's
 210 foreach_property_cb() function.  We should add some private fields to the
 211 NMAccessPoint object (defined in nm-wifi-ap.c) to remember whether a specific
 212 AP supports WPS and what WPS methods it supports, and expose that over D-Bus to
 213 GUI clients as well.
 214
 215 There are two common WPS setup methods: PIN and button.  For PIN, the router
 216 either displays a random PIN on an LCD or the router's web UI, or a static PIN
 217 is printed on the router itself.  The user enters that PIN instead of a PSK
 218 when connecting.  For the "button" method, the router has a physical button that
 219 when pushed, allows any client to connect for a short period of time.
 220
 221 We'll then need to add some properties to the NMSettingWirelessSecurity setting
 222 for the WPS PIN code so that when the user enters it through the GUI, it can
 223 be passed back to NM.  And we'll need to figure out some mechanism for passing
 224 back an indication that the user pushed the button on the router for the
 225 pushbutton method.
 226
 227 When connecting to a new access point that supports WPS, the GUI client would
 228 call the AddAndActivateConnection method and wait for NM to request secrets.
 229 NM would determine that the AP supports WPS, and request WPS secrets from the
 230 applet.  The applet would ask the user for a PIN, or to push the button on the
 231 AP, instead of asking for a passphrase or PSK.  When the user has entered the
 232 PIN or pushed the button, the applet returns this information to NM, which
 233 proceeds with the connection.
 234
 235 NM sends the correct wpa_supplicant config for WPS to the supplicant, and waits
 236 for the connection to occur.  WPS can only be used the *first* time, so after a
 237 first successfull connection, NM must request the actual hexadecimal PSK from
 238 wpa_supplicant via D-Bus, and store that PSK in the connection, clear any WPS
 239 PIN code from the connection, and save the connection to backing storage.
 240
 241 Any applet GUI should also allow the user to enter the PSK instead of completing
 242 association using WPS, since quite a few routers out there are broken, or
 243 because the user has no physical access to the router itself, but has been given
 244 as passphrase/PSK instead.
 245