based on it and the device's state.
-* 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
-
-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).
-
-
-* 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.
-
-Note that some devices (airo, ipw2100, ipw2200, iwl3945, iwl4965, atmel, zd1201)
-will never support AP mode due to firmware limitations, so we clearly must still
-provide Ad-Hoc connection sharing support for those devices and switch between
-Ad-Hoc and AP mode depending on device capabilities.
-
-
-* 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.
-
-
-* 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
successfully connect to this network.
-* VPN re-connect
+* VPN re-connect (bgo #349151)
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.
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
it tracks which network connections are active, and it already queries the
network for automatic proxy configuration via DHCP and WPAD.
+However, proxy handling is complicated and may require use of Javascript to
+parse PAC files provided by WPAD, and this is not something NetworkManager
+should do itself. Instead, that should be left to "proxy handlers", or external
+utilities like libproxy or pacrunner that take raw proxy information, parse it,
+and tell applications what proxy server to use for a specific network resource.
+NetworkManager should provide all the proxy information it can find to these
+external proxy handlers via the D-Bus interface and dispatcher scripts.
+
We should add a new NMSetting subclass called NMSettingProxy that holds
necessary proxy configuration. The properties of this setting should be a
superset of what is provided in the Firefox proxy configuration screen and the
After completing IP configuration but still during the NM_DEVICE_STATE_IP_CONFIG
activation stage, NetworkManager would merge the automatically supplied proxy
configuration (from DHCP's WPAD option) with user-provided overrides from the
-NMSettingProxy and send the results to the system. The 'default' connection's
-proxy configuration would be preferred, so we'd have to update proxy
-configuration from nm-policy.c the same time we update DNS information and the
-default route.
-
-The merged proxy configuration would then be sent to the system. There is no
-canonical proxy daemon in-use, so we should have plugins (if not separate
-shared libraries, then certainly encapsulated source files that implement a
-common glib GInterface or are subclasses of eg a parent NMProxyHandler class)
-that handle different system proxy handlers. Some of the proxy handlers are:
-
- libproxy: need to figure out how it gets proxy info and have NM write merged
- proxy config out to that location
- pacrunner: a D-Bus enabled daemon, NM would call D-Bus methods of the
- pacrunner service with the proxy information
- GNOME/KDE: how do these desktop environments retrieve proxy configuration?
-
-
-* Bridging and Bonding Support
-
-The largest complication here is that NetworkManager normally operates on
-physical interfaces, while bridging and bonding involve tying multiple physical
-interfaces together into a logical interface. This has interesting implications
-for the D-Bus API and the NM device model. The first complication is that
-we may need to do 802.1x port authentication on an interface before it can
-communicate with the other side of the link, and those credentials may be
-different for each interface; thus we may need to do separate 802.1x
-operations on each interface that is part of a bridge/bond before adding each
-one to the master bridge/bond interface.
-
-In this way bridge/bond interfaces may be treated the same way as NetworkManager
-treats VPN interfaces already; one or more physical interface NMConnections must
-be activated before the master bridge/bond interface's NMConnection can be
-activated, though this all happens internally.
-
-To enable bridging and bonding in the NMConnection itself, we should create
-new NMSettingBridge and NMSettingBond classes that contain information specific
-to each. Both settings would contain a 'components' property with an
-'array of string' type which would contain the UUIDs of the Connections of
-physical interfaces that compose the bridge or bond. Thus NetworkManager would
-have the necessary information to tie lower-level interface configuration
-(802.1x, MTU, MAC address locking, duplex mode, speed, etc) to each physical
-interface that will be part of the bridge/bond, configure the interface with
-it, and then configure the master bridge/bond interface at upper layers using
-configuration specific for the bridge/bond interface (like IP details). Thus
-for a single active bridge, two or more NMConnections would be activated; one
-for each physical interface component of the bridge/bond, and one for the master
-bridge/bond interface itself.
-
-NMSettingBridge would contain at least the following keys:
-
- components: (array of string) UUIDs of component connections
- stp: (boolean) on to enable STP, off to disable
-
-NMSettingBond would contain at least the following keys:
-
- components: (array of string) UUIDs of component connections
- mode: (string) one of "balance-rr", "active-backup", "balance-xor",
- "broadcast", "802.3ad", "balance-tlb", or "balance-alb"
- monitor-interval: (uint) Specifies link monitoring interval (in milliseconds);
- NM will always enable netlink carrier monitoring if this
- value is non-zero so this property only affects speed and
- duplex checking
-
-In the future we may consider adding other bonding parameters like "up-delay"
-and "down-delay".
-
-Then we'd add a 'component' (boolean) property to NMSettingConnection to
-indicate that the component interface connections were in fact components of
-a bridge or bond and shouldn't be automatically started by NetworkManager or
-displayed as separate connections in the user interface.
-
-TO BE CONTINUED
+NMSettingProxy export the resulting proxy configuration via D-Bus and dispatcher
+scripts. The 'default' connection's proxy configuration would be preferred, so
+we'd have to update proxy configuration from nm-policy.c the same time we update
+DNS information and the default route.
+
+Merged proxy information should be exposed in two places. First, it should be
+exported over D-Bus as a property of the org.freedesktop.NetworkManager.Device
+interface. This property should be named "ProxyInfo" and should have the
+D-Bus signature "a{sv}" (eg, dictionary) and should mirror the properties from
+the NMSettingProxy object.
+
+Second, it should be exported via the dispatcher to dispatcher scripts when
+with the "up" and "down" events.
* Better Tablet/Mobile Behavior
the best route to go for desktop use-cases as well. Instead of bringing all
available connections up, only bring up the "best" connection at any given
time based on the current priority list (which is rougly Ethernet > WiFi >
-3G/Bluetooth/WiMAX). However, to ensure seamless connectivity, when one
-connection begins to degrade, the next-best connection should be started before
-the current one is terminated, such that there is a small amount of overlap.
+3G/Bluetooth). However, to ensure seamless connectivity, when one connection
+begins to degrade, the next-best connection should be started before the
+current one is terminated, such that there is a small amount of overlap.
Consequently the same behavior should be used when a better connection becomes
available. This behavior should be suspended when special connections like
Internet Connection Sharing ones are started, where clearly the priorities
are different (ie, for Mobile Hotspot 3G > WiFi).
-
-
-* IP over Infiniband (IPoIB)
-
-These interfaces are similar to Ethernet interfaces with a few distinct
-differences:
-
- 1) they have 64-bit MAC addresses (GUIDs in Infiniband parlance)
- 2) DHCP clients need to be modified to handle IPoIB
- 3) they have a different ARP type and different L2 options
-
-By default the interfaces do not have IP capability, but they gain that
-capability when certain kernel modules (ib_ipoib.ko) are loaded, which causes
-the IP-capable interface is created. The IP-capable interfaces apparently have
-ARPHRD_INFINIBAND set, which is likely what NM should use to identify them.
-
-One outstanding question is whether NM should (a) detect all Infiniband
-interfaces and load ib_ipoib.ko only when there is a defined NMConnection for
-an Infiniband interface, or (b) whether NM should automatically load ib_ipoib.ko
-for every Infiniband interface, or (c) whether NM should only manage Infiniband
-interfaces that already have associated IP-capable interfaces (ie, something
-else is responsible for loading ib_ipoib.ko). Depending on our implementation,
-(a) might not be possible, because if IPoIB connections are treated similar to
-plain Ethernet connections, we may not have any information about whether a
-specific NMConnection is Infiniband other than the MAC address.
-
-It turns out that on some distros other components (like system services) may
-load ib_ipoib.ko for us. For exmaple, the 'rdma' package on Fedora/RHEL systems
-contains /etc/rc.d/init.d/rdma which uses values in /etc/rdma/rdma.conf to load
-ib_ipoib.ko at system startup if the user has requested it via IPOIB_LOAD=yes.
-For the time being, if the some other component of the system loads IP for us,
-NetworkManager should probably still recognize the Infiniband interface, but
-leave it in unmanaged mode if there is no available IPoIB interface associated
-with the Infiniband one. i.e. for now, NM should not automatically load
-ib_ipoib.ko.
-
-The second question is whether to fold IPoIB support into the NMDeviceEthernet
-class as was done for s390 network interfaces, or whether to create a subclass
-of NMDevice:
-
-1) extend NMDeviceEthernet: this would involve loosening the assumption that
-hardware addresses (the 'hw-address'/'perm-hw-address' properties of
-NMDeviceEthernet and the 'mac-address'/'cloned-mac-address' properties of
-NMSettingWired) are 48 bits wide and instead can be either 48 or 64 bits wide.
-
-2) create a new NMDevice subclass for Infiniband devices tailored to Infiniband
-specific behavior and attributes. This would be a lot more code since we'd have
-to duplicate much of what NMDeviceEthernet already does, plus add the
-Infiniband device class to libnm-glib. This also would be the least invasive
-from an API standpoint since the existing API would be unchanged, except for
-the addition of a new value in the NMDeviceType enum, which clients should
-ignore if they don't understand it. (Need to coordinate additions to this enum
-between 0.8.x and 0.9.x since 0.9.x has more device types, but we want to make
-sure new device types get the same number for both branches).
-
-For Infiniband specific options we could either fold them into NMSettingEthernet
-or create a new NMSettingInfiniband class. Current Infiniband specific options
-are partitions/P_Keys, datagram vs. connected mode, and MTU. The default MTU
-varies with the 'mode'; for datagram it is currently 2044, while for connected
-mode it is currently 65520. Given that we only have 2 IB-specific options
-we should probably just fold them into NMSettingEthernet similar to what was
-done for s390-specific options.
-
-For some general (and also Red Hat/Fedora specific) information see:
-
-http://tools.ietf.org/html/rfc4392
-http://rhkernel.org/#RHEL6+2.6.32-71.18.2.el6/Documentation/infiniband/ipoib.txt
-
projects / NetworkManager.git / blobdiff