diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 244 |
1 files changed, 0 insertions, 244 deletions
@@ -1,245 +1 @@ -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. |