|NetworkManager D-Bus Reference Manual|
NetworkManager 0.9 is a new major version of NetworkManager that breaks both API and ABI compared to previous versions. These changes are intended to make communication with NetworkManager much simpler, especially for network control and configuration programs. Thankfully, most changes are not difficult to implement, and the advantages of the simpler architecture of NetworkManager 0.9 greatly outweight the effort of updating client programs.
This section details the architectural and D-Bus API changes in NetworkManager 0.9.
Previously there were two "settings services", or D-Bus services that provided and saved network configuration information. NetworkManager owned the "system" settings service, and one user-level applet owned the "user" settings service. Now, the "user" settings service has been eliminated, so clients only have to track one D-Bus service to read and update network configuration. The functionality of the old user settings service has been replaced with a "permissions" key on each connection object to preserve the ability to restrict which users can use the connection, and with a "secret agent" D-Bus API for user-session-level secure storage of network secrets and passwords.
Elimination of the user settings service provides the following advantages for clients of NetworkManager:
With this change, D-Bus methods that previously took a "service name"
objects with service name properties (like ActiveConnection objects) no
longer have those arguments or properties.
Action: if you develop a network control applet that talks to NetworkManager and used to provide a user settings service, you can eliminate that code and rely on NetworkManager for all storage of network configuration. Your applet should now implement the Secret Agent D-Bus API (see below) to store user-specific secrets, and add legacy user-specific configuration to NetworkManager when run. More information about both these changes follows.
Even with the elimination of the user settings service, in some cases it
is still desirable to store secrets in the user's session and not in
system-wide storage (and thus available to all users). To allow this
functionality the concept of agents has been introduced. Using the new
D-Bus interface provided by NetworkManager, user applications can register
themselves as "secret agents", ie programs capable of saving and providing
secrets to NetworkManager. The agent should export the
D-Bus interface, but should NOT claim a bus name on the system or session
bus. Instead, NetworkManager talks to the agent directly over the D-Bus
connection which the agent used to register itself.
Each agent must send a unique identifier to NetworkManager when it registers. This identifier must follow certain rules (see the NM D-Bus API documentation for more details) but looks essentially the same as a D-Bus service name. Only one agent using a given identifier may be registered at the same time. The agent is automatically unregistered if it disconnects from D-Bus or exits.
When NetworkManager requires secrets during the attempt to connect to a network, and no secrets are available from the internal settings service, NetworkManager queries each registered agent for secrets. Agents that are in "active" user sessions (as determined by ConsoleKit) are preferred over inactive ones. Only agents belonging to users who have permission to view and modify the connection are queried. For more information on connection permissions, see below.When secrets are requested, the agent is also sent a set of flags that modify the behavior of the request. By default, the agent should never attempt to query the user for secrets, but should simply return any available saved secrets. Other flags allow the agent to explicitly request new secrets from the user.
Action: the parts of a previous user settings service that handled secrets may be easily repurposed as the bulk of the implementation of a secret agent. The agent is sent all available connection settings, and from those should be able to retrieve or save any saved user secrets, or to request new secrets from the user.
With the elimination of the user settings service, the old
service names are no longer used. Instead NetworkManager provides the
settings service using its own D-Bus service name,
org.freedesktop.NetworkManager. The object path of
the settings service has also changed to
Additionally, the D-Bus interface of the settings service has changed
the old interface name of
org.freedesktop.NetworkManagerSettings, and the old
interface has been merged into the new
as the split no longer made sense. This includes the
SaveHostname method and the
Action: change the service name and
object path that your application uses to request system network settings
and update the D-Bus interface that codes uses to talk to the settings
Listen for hostname changes using the new interface name as well.
Consistent with the interface changes to the Settings object, the
Connection object's D-Bus interface has changed to
from the previous
signal of the Connection object no longer includes the updated settings
data argument, as that might allow users who are not authorized to
view the connection details to do so. Instead, when a client receives the
Updated signal, it should requery the Connection's settings with the
method. If the client receives an error as a result of this method call,
it should assume the connection has been deleted.
Action: where code manipulates
Connection objects, update the D-Bus interface that code uses to be
Additionally, code that listens for the
signal should no longer expect the new settings data as an argument, but
instead should request the new settings data using the
Previously there were two D-Bus method calls to retrieve the list of operations that a user client could perform, and two signals notifying callers that they should recheck permissions. Those two calls were:
org.freedesktop.NetworkManagerSettings.System.GetPermissionswhich returned a bitfield of operations the caller was allowed to perform related to modify system network settings and the machine hostname
org.freedesktop.NetworkManager.GetPermissionswhich returned a dictionary mapping permission names to result strings like "yes", "auth", or "no", relating to network control permissions like the ability to enable or disable WiFi.
These two calls have been consolidated into an enhanced
org.freedesktop.NetworkManager.GetPermissions call that
uses the same arguments, but includes all permissions, including those which
the settings service used to handle.
With this change, the bitfield items from
are now string-based permissions. The mapping is as follows:
|Old bitfield value||New permission name|
Action: modify handling of existing
code that checks permissions to recognize the new permissions names for
old system settings permissions, and remove code that used to call
method call now returns the object path of the newly added
connection. Previously, if code wanted to manipulate a connection
post-addition, it had to wait for the new connection to be announced via
the NewConnection signal by matching connection UUIDs. Now the object
path is returned and this workaround is no longer required.
Action: update code that adds new connections to handle the object path returned from AddConnection, and remove workarounds for finding the new connection via signals.
NetworkManager now supports Intel WiMAX mobile broadband devices. A
corresponding device type (
D-Bus interface have been added. Furthermore, to support connection to
different WiMAX Network Service Providers (NSPs) the
interface has been added to access information about each available
Action: update code that handles devices and/or displays status to users to recognize the new device type, and to display available WiMAX NSPs similar to how WiFi Access Points are displayed. Also update code that creates new connections to allow creation of new WiMAX connections.
A few new device states have been added, and all device states have been renumbered for flexibility. The new devices states IP_CHECK, SECONDARIES, and DEACTIVATING.
Action: where code checks device state or shows UI indication of the device's state, make sure the new device states are processed correctly, and that code in switch()-type statements is updated to handle the new states.
Along with the new device states, an additional ActiveConnection state has been added: DEACTIVATING. This state is entered when the connection is being torn down and deactivated.
Action: where code checks active connection states or shows UI indication of active connection states, make sure the DEACTIVATING state is processed correctly, and that code in switch()-type statements is updated to handle it.
Many new mobile broadband devices support multiple access families, like Qualcomm Gobi cards (CDMA/EVDO and GSM/UMTS), or multi-mode EVDO/LTE or UMTS/LTE modems like the Pantech UML290. The previous hard split between CDMA/EVDO and GSM/UMTS device classes was not flexible enough to deal with these new multi-mode devices. Thus the previously separate CDMA and GSM device classes have been combined into a single Modem device class, which exposes both hardware "ModemCapabilities" and runtime "CurrentCapabilities" which represent generic access technology families like CDMA/EVDO, GSM/UMTS, and LTE which the device supports. ModemCapabilities indicate all the access technology families which the modem is capable of supporting, while CurrentCapabilities indicate the immediate access technology families the device supports without reloading the firmware and thus restarting the device.
Along with this change, the
interface has been removed as it's functionality will be incorporated
interface in the future.
Action: combine code that checks for the old CDMA and GSM device types, and instead handle the new Modem device type. Where behavior must change based on the capabilities of the device, check the CurrentCapabilities device property to determine whether to treat the device as CDMA, GSM, or LTE for purposes of configuration and status.
In the Connection object's configuration properties, each setting's secret properties (like WiFi passphrases, or public key passwords, etc) now has an associated "flags" property that changes how NetworkManager treats the secret. The "flags" property is a bitfield of one or more of the following values:
|NetworkManager is responsible for providing and storing this secret (default)|
|A user secret agent is responsible for providing and storing this secret; when it is required agents will be asked to retrieve it|
0x02 (not saved)
|The secret is not saved, and should be requested each time it is required. Used for OTP/token configurations where the secret changes periodically, or if the user simply wants to manually enter the secret each time.|
0x04 (not required)
|In situations where it cannot be automatically determined that the secret is required (some VPNs and PPP providers dont require all possible secrets) this flag indicates that the specific secret is not required.|
Action: user interface code which handles entry of connection secrets should be updated to read and set secret flags. For example, code that creates new VPN connections may want to set the "agent-owned" flag to ensure that the user's VPN password is not available to all users. EAP-TLS and VPN interface code might add a checkbox that toggles the "not saved" bit to indicate that the password/PIN code should be requested from a hardware token each time it is required.
A few methods and signals of the
interface deprecated in version 0.7 have been removed. All the
replacement methods and signals have existed since version 0.7 and so are
not new to this version of NetworkManager, but some older programs may
be using removed items. The following table lists the removed items and
sleep() and wake() methods
Action: update code to use these replacement methods and properties where it used old deprecated ones