path: root/TODO

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.