Migrating from NetworkManager 0.8 to 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" argument (like org.freedesktop.NetworkManager.ActivateConnection) and 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 org.freedesktop.NetworkManager.AgentManager 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 org.freedesktop.NetworkManager.SecretAgent 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.

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 org.freedesktop.NetworkManagerUserSettings and org.freedesktop.NetworkManagerSystemSettings D-Bus 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 /org/freedesktop/NetworkManager/Settings.

Additionally, the D-Bus interface of the settings service has changed to org.freedesktop.NetworkManager.Settings from the old interface name of org.freedesktop.NetworkManagerSettings, and the old org.freedesktop.NetworkManagerSettings.System interface has been merged into the new org.freedesktop.NetworkManager.Settings interface as the split no longer made sense. This includes the SaveHostname method and the Hostname and CanModify properties.

Action: change the service name and object path that your application uses to request system network settings to org.freedesktop.NetworkManager and /org/freedesktop/NetworkManager/Settings respectively, and update the D-Bus interface that codes uses to talk to the settings service to org.freedesktop.NetworkManager.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 org.freedesktop.NetworkManager.Settings.Connection from the previous org.freedesktop.NetworkManagerSettings.Connection.

Additionally, the org.freedesktop.NetworkManager.Settings.Connection.Updated 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 org.freedesktop.NetworkManager.Settings.Connection.GetSettings 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 org.freedesktop.NetworkManager.Settings.Connection. Additionally, code that listens for the org.freedesktop.NetworkManager.Settings.Connection.Updated signal should no longer expect the new settings data as an argument, but instead should request the new settings data using the org.freedesktop.NetworkManager.Settings.Connection.GetSettings method.

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:

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 org.freedesktop.NetworkManagerSettings.System.GetPermissions are now string-based permissions. The mapping is as follows:

0x1 (connection-modify)

0x2 (wifi-share-protected)

0x4 (wifi-share-open)

0x8 (hostname-modify)

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 org.freedesktop.NetworkManagerSettings.System.GetPermissions.

The org.freedesktop.NetworkManager.Settings.AddConnection 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 (NM_DEVICE_TYPE_WIMAX) and a new org.freedesktop.NetworkManager.Device.WiMax D-Bus interface have been added. Furthermore, to support connection to different WiMAX Network Service Providers (NSPs) the org.freedesktop.NetworkManager.Device.WiMax.Nsp interface has been added to access information about each available WiMAX network.

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 org.freedesktop.NetworkManager.Device.Serial interface has been removed as it's functionality will be incorporated into the org.freedesktop.NetworkManager.Device.Modem 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:

0x00 (none)

0x01 (agent-owned)

0x02 (not saved)

0x04 (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 org.freedesktop.NetworkManager 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 their replacements:

StateChange signal

sleep() and wake() methods

Action: update code to use these replacement methods and properties where it used old deprecated ones