Networking state is unknown. This indicates a daemon error -that makes it unable to reasonably assess the state. In such event the -applications are expected to assume Internet connectivity might be present -and not disable controls that require network access. -The graphical shells may hide the network accessibility indicator altogether -since no meaningful status indication can be provided.

Networking is not enabled, the system is being suspended or -resumed from suspend.

There is no active network connection. -The graphical shell should indicate no network connectivity and the -applications should not attempt to access the network.

Network connections are being cleaned up. -The applications should tear down their network sessions.

A network connection is being started -The graphical shell should indicate the network is being connected while -the applications should still make no attempts to connect the network.

There is only local IPv4 and/or IPv6 connectivity, -but no default route to access the Internet. The graphical shell should -indicate no network connectivity.

There is only site-wide IPv4 and/or IPv6 connectivity. -This means a default route is available, but the Internet connectivity check -(see "Connectivity" property) did not succeed. The graphical shell should -indicate limited network connectivity.

There is global IPv4 and/or IPv6 Internet connectivity -This means the Internet connectivity check succeeded, the graphical shell should -indicate full network connectivity.

Network connectivity is unknown. This means the -connectivity checks are disabled (e.g. on server installations) or has -not run yet. The graphical shell should assume the Internet connection -might be available and not present a captive portal window.

The host is not connected to any network. There's -no active connection that contains a default route to the internet and -thus it makes no sense to even attempt a connectivity check. The graphical -shell should use this state to indicate the network connection is unavailable.

The Internet connection is hijacked by a captive -portal gateway. The graphical shell may open a sandboxed web browser window -(because the captive portals typically attempt a man-in-the-middle attacks -against the https connections) for the purpose of authenticating to a gateway -and retrigger the connectivity check with CheckConnectivity() when the -browser window is dismissed.

The host is connected to a network, does not appear -to be able to reach the full Internet, but a captive portal has not been -detected.

The host is connected to a network, and -appears to be able to reach the full Internet.

for both devices and access point objects, indicates -the object is part of an Ad-Hoc 802.11 network without a central -coordinating access point.

the device or access point is in infrastructure mode. -For devices, this indicates the device is an 802.11 client/station. For -access point objects, this indicates the object is an access point that -provides connectivity to clients.

the device is an access point/hotspot. Not valid for -access point objects; used only for hotspot mode on the local machine.

the device is managed by NetworkManager, but -is not available for use. Reasons may include the wireless switched off, -missing firmware, no ethernet carrier, missing supplicant or modem manager, -etc.

the device can be activated, but is currently -idle and not connected to a network.

the device is preparing the connection to the -network. This may include operations like changing the MAC address, -setting physical link properties, and anything else required to connect -to the requested network.

the device is connecting to the requested network. -This may include operations like associating with the Wi-Fi AP, dialing -the modem, connecting to the remote Bluetooth device, etc.

the device requires more information to continue -connecting to the requested network. This includes secrets like WiFi -passphrases, login passwords, PIN codes, etc.

the device is requesting IPv4 and/or IPv6 -addresses and routing information from the network.

the device is checking whether further action is -required for the requested network connection. This may include checking -whether only local network access is available, whether a captive portal -is blocking access to the Internet, etc.

the device is waiting for a secondary -connection (like a VPN) which must activated before the device can be -activated

a disconnection from the current network -connection was requested, and the device is cleaning up resources used for -that connection. The network connection may still be valid.

the device failed to connect to the requested -network and is cleaning up the connection request

enum NMMetered

The NMMetered enum has two different purposes: one is to configure +"connection.metered" setting of a connection profile in NMSettingConnection, and +the other is to express the actual metered state of the NMDevice at a given moment.

For the connection profile only NM_METERED_UNKNOWN, NM_METERED_NO +and NM_METERED_YES are allowed.

The device's metered state at runtime is determined by the profile +which is currently active. If the profile explicitly specifies NM_METERED_NO +or NM_METERED_YES, then the device's metered state is as such. +If the connection profile leaves it undecided at NM_METERED_UNKNOWN (the default), +then NetworkManager tries to guess the metered state, for example based on the +device type or on DHCP options (like Android devices exposing a "ANDROID_METERED" +DHCP vendor option). This then leads to either NM_METERED_GUESS_NO or NM_METERED_GUESS_YES.

Most applications probably should treat the runtime state NM_METERED_GUESS_YES +like NM_METERED_YES, and all other states as not metered.

Note that the per-device metered states are then combined to a global metered +state. This is basically the metered state of the device with the best default +route. However, that generalization of a global metered state may not be correct +if the default routes for IPv4 and IPv6 are on different devices, or if policy +routing is configured. In general, the global metered state tries to express whether +the traffic is likely metered, but since that depends on the traffic itself, +there is not one answer in all cases. Hence, an application may want to consider +the per-device's metered states.

Members

@@ -2463,14 +2502,14 @@ network and is cleaning up the connection request

@@ -2509,8 +2548,8 @@ network and is cleaning up the connection request

@@ -2518,8 +2557,8 @@ value, which is

NM_CONNECTION_MULTI_CONNECT_SINGLE

@@ -2527,9 +2566,9 @@ will first deactivate it.

@@ -2537,7 +2576,7 @@ currently not connected otherwise.

@@ -2586,7 +2625,7 @@ network.

@@ -2594,7 +2633,7 @@ torn down and cleaned up

@@ -2619,7 +2658,7 @@ and will be removed

@@ -2627,7 +2666,7 @@ state change is unknown.

@@ -2635,7 +2674,7 @@ connection state change.

@@ -2643,7 +2682,7 @@ state because the user disconnected it.

@@ -2651,7 +2690,7 @@ changed state because the device it was using was disconnected.

@@ -2659,7 +2698,7 @@ VPN connection was stopped.

@@ -2667,7 +2706,7 @@ connection was invalid.

@@ -2675,7 +2714,7 @@ the VPN service timed out.

@@ -2683,7 +2722,7 @@ while starting the service providing the VPN connection.

@@ -2691,7 +2730,7 @@ providing the VPN connection failed.

@@ -2699,7 +2738,7 @@ connection were not provided.

@@ -2707,7 +2746,7 @@ server failed.

@@ -2715,7 +2754,7 @@ deleted from settings.

@@ -2723,7 +2762,7 @@ connection failed to activate.

@@ -2731,7 +2770,7 @@ software device link.

@@ -2757,8 +2796,8 @@ depended on disappeared.

@@ -2766,8 +2805,8 @@ persistent storage, or if no secrets are available an error is returned.

@@ -2775,9 +2814,9 @@ required, or if none are found in persistent storage.

@@ -2785,9 +2824,9 @@ is allowed.

@@ -2795,8 +2834,8 @@ results or carrier changes.

@@ -2804,7 +2843,7 @@ on the router instead of supplying a PSK.

@@ -2812,7 +2851,7 @@ the D-Bus API.

@@ -3123,7 +3162,7 @@ VPN plugin authentication dialogs.

@@ -3131,7 +3170,7 @@ a new checkpoint, destroy all existing ones.

@@ -3139,7 +3178,7 @@ delete any new connection added after the checkpoint (Since: 1.6)

@@ -3147,17 +3186,17 @@ disconnect any new device appeared after the checkpoint (Since: 1.6)

@@ -3236,9 +3275,9 @@ of an older checkpoint. (Since: 1.12)

@@ -3246,9 +3285,9 @@ but has modifications in-memory that were not persisted to disk.

@@ -3256,10 +3295,10 @@ and has no backing file as it is in-memory only.

@@ -3327,7 +3366,7 @@ in-memory only.

@@ -3335,9 +3374,9 @@ This only makes sense if the device is a master.

@@ -3384,9 +3423,9 @@ for the user exists. Since: 1.16

@@ -3425,16 +3464,16 @@ is manually activated.

@@ -3442,12 +3481,12 @@ allow deletion, and nmmeta file is written to mark the UUID as deleted).

@@ -3455,9 +3494,9 @@ storage is taken over again.

@@ -3465,14 +3504,14 @@ a new, unused filename will be chosen.

@@ -3480,9 +3519,9 @@ clear the volatile flag.

@@ -3490,12 +3529,12 @@ is manually activated.

@@ -3543,9 +3582,121 @@ the profile. Since: 1.20.

Since: 1.14

enum NMManagerReloadFlags

Flags for the manager Reload() call.

Members

NM_METERED_YES	- Metered, the value was statically set + Metered, the value was explicitly configured
NM_METERED_NO	- Not metered, the value was statically set + Not metered, the value was explicitly configured
NM_CONNECTION_MULTI_CONNECT_DEFAULT	indicates that the per-connection -setting is unspecified. In this case, it will fallback to the default -value, which is `NM_CONNECTION_MULTI_CONNECT_SINGLE`. + setting is unspecified. In this case, it will fallback to the default + value, which is `NM_CONNECTION_MULTI_CONNECT_SINGLE`.
the connection profile can only -be active once at each moment. Activating a profile that is already active, -will first deactivate it. + be active once at each moment. Activating a profile that is already active, + will first deactivate it.
NM_CONNECTION_MULTI_CONNECT_MANUAL_MULTIPLE	the profile can -be manually activated multiple times on different devices. However, -regarding autoconnect, the profile will autoconnect only if it is -currently not connected otherwise. + be manually activated multiple times on different devices. However, + regarding autoconnect, the profile will autoconnect only if it is + currently not connected otherwise.
NM_CONNECTION_MULTI_CONNECT_MULTIPLE	the profile can autoactivate -and be manually activated multiple times together. + and be manually activated multiple times together.
NM_ACTIVE_CONNECTION_STATE_DEACTIVATING	the network connection is being -torn down and cleaned up + torn down and cleaned up
NM_ACTIVE_CONNECTION_STATE_DEACTIVATED	the network connection is disconnected -and will be removed + and will be removed
NM_ACTIVE_CONNECTION_STATE_REASON_UNKNOWN	The reason for the active connection -state change is unknown. + state change is unknown.
NM_ACTIVE_CONNECTION_STATE_REASON_NONE	No reason was given for the active -connection state change. + connection state change.
NM_ACTIVE_CONNECTION_STATE_REASON_USER_DISCONNECTED	The active connection changed -state because the user disconnected it. + state because the user disconnected it.
NM_ACTIVE_CONNECTION_STATE_REASON_DEVICE_DISCONNECTED	The active connection -changed state because the device it was using was disconnected. + changed state because the device it was using was disconnected.
NM_ACTIVE_CONNECTION_STATE_REASON_SERVICE_STOPPED	The service providing the -VPN connection was stopped. + VPN connection was stopped.
NM_ACTIVE_CONNECTION_STATE_REASON_IP_CONFIG_INVALID	The IP config of the active -connection was invalid. + connection was invalid.
NM_ACTIVE_CONNECTION_STATE_REASON_CONNECT_TIMEOUT	The connection attempt to -the VPN service timed out. + the VPN service timed out.
NM_ACTIVE_CONNECTION_STATE_REASON_SERVICE_START_TIMEOUT	A timeout occurred -while starting the service providing the VPN connection. + while starting the service providing the VPN connection.
NM_ACTIVE_CONNECTION_STATE_REASON_SERVICE_START_FAILED	Starting the service -providing the VPN connection failed. + providing the VPN connection failed.
NM_ACTIVE_CONNECTION_STATE_REASON_NO_SECRETS	Necessary secrets for the -connection were not provided. + connection were not provided.
NM_ACTIVE_CONNECTION_STATE_REASON_LOGIN_FAILED	Authentication to the -server failed. + server failed.
NM_ACTIVE_CONNECTION_STATE_REASON_CONNECTION_REMOVED	The connection was -deleted from settings. + deleted from settings.
NM_ACTIVE_CONNECTION_STATE_REASON_DEPENDENCY_FAILED	Master connection of this -connection failed to activate. + connection failed to activate.
NM_ACTIVE_CONNECTION_STATE_REASON_DEVICE_REALIZE_FAILED	Could not create the -software device link. + software device link.
NM_ACTIVE_CONNECTION_STATE_REASON_DEVICE_REMOVED	The device this connection -depended on disappeared. + depended on disappeared.
NM_SECRET_AGENT_GET_SECRETS_FLAG_NONE	no special behavior; by default no -user interaction is allowed and requests for secrets are fulfilled from -persistent storage, or if no secrets are available an error is returned. + user interaction is allowed and requests for secrets are fulfilled from + persistent storage, or if no secrets are available an error is returned.
NM_SECRET_AGENT_GET_SECRETS_FLAG_ALLOW_INTERACTION	allows the request to -interact with the user, possibly prompting via UI for secrets if any are -required, or if none are found in persistent storage. + interact with the user, possibly prompting via UI for secrets if any are + required, or if none are found in persistent storage.
NM_SECRET_AGENT_GET_SECRETS_FLAG_REQUEST_NEW	explicitly prompt for new -secrets from the user. This flag signals that NetworkManager thinks any -existing secrets are invalid or wrong. This flag implies that interaction -is allowed. + secrets from the user. This flag signals that NetworkManager thinks any + existing secrets are invalid or wrong. This flag implies that interaction + is allowed.
NM_SECRET_AGENT_GET_SECRETS_FLAG_USER_REQUESTED	set if the request was -initiated by user-requested action via the D-Bus interface, as opposed to -automatically initiated by NetworkManager in response to (for example) scan -results or carrier changes. + initiated by user-requested action via the D-Bus interface, as opposed to + automatically initiated by NetworkManager in response to (for example) scan + results or carrier changes.
NM_SECRET_AGENT_GET_SECRETS_FLAG_WPS_PBC_ACTIVE	indicates that WPS enrollment -is active with PBC method. The agent may suggest that the user pushes a button -on the router instead of supplying a PSK. + is active with PBC method. The agent may suggest that the user pushes a button + on the router instead of supplying a PSK.
NM_SECRET_AGENT_GET_SECRETS_FLAG_ONLY_SYSTEM	Internal flag, not part of -the D-Bus API. + the D-Bus API.
NM_SECRET_AGENT_GET_SECRETS_FLAG_NO_ERRORS	Internal flag, not part of -the D-Bus API. + the D-Bus API.
NM_CHECKPOINT_CREATE_FLAG_DESTROY_ALL	when creating -a new checkpoint, destroy all existing ones. + a new checkpoint, destroy all existing ones.
NM_CHECKPOINT_CREATE_FLAG_DELETE_NEW_CONNECTIONS	upon rollback, -delete any new connection added after the checkpoint (Since: 1.6) + delete any new connection added after the checkpoint (Since: 1.6)
NM_CHECKPOINT_CREATE_FLAG_DISCONNECT_NEW_DEVICES	upon rollback, -disconnect any new device appeared after the checkpoint (Since: 1.6) + disconnect any new device appeared after the checkpoint (Since: 1.6)
NM_CHECKPOINT_CREATE_FLAG_ALLOW_OVERLAPPING	by default, creating -a checkpoint fails if there are already existing checkoints that -reference the same devices. With this flag, creation of such -checkpoints is allowed, however, if an older checkpoint -that references overlapping devices gets rolled back, it will -automatically destroy this checkpoint during rollback. This -allows to create several overlapping checkpoints in parallel, -and rollback to them at will. With the special case that -rolling back to an older checkpoint will invalidate all -overlapping younger checkpoints. This opts-in that the -checkpoint can be automatically destroyed by the rollback -of an older checkpoint. (Since: 1.12) + a checkpoint fails if there are already existing checkoints that + reference the same devices. With this flag, creation of such + checkpoints is allowed, however, if an older checkpoint + that references overlapping devices gets rolled back, it will + automatically destroy this checkpoint during rollback. This + allows to create several overlapping checkpoints in parallel, + and rollback to them at will. With the special case that + rolling back to an older checkpoint will invalidate all + overlapping younger checkpoints. This opts-in that the + checkpoint can be automatically destroyed by the rollback + of an older checkpoint. (Since: 1.12)
NM_SETTINGS_CONNECTION_FLAG_UNSAVED	the connection is not saved to disk. -That either means, that the connection is in-memory only and currently -is not backed by a file. Or, that the connection is backed by a file, -but has modifications in-memory that were not persisted to disk. + That either means, that the connection is in-memory only and currently + is not backed by a file. Or, that the connection is backed by a file, + but has modifications in-memory that were not persisted to disk.
NM_SETTINGS_CONNECTION_FLAG_NM_GENERATED	A connection is "nm-generated" if -it was generated by NetworkManger. If the connection gets modified or saved -by the user, the flag gets cleared. A nm-generated is also unsaved -and has no backing file as it is in-memory only. + it was generated by NetworkManger. If the connection gets modified or saved + by the user, the flag gets cleared. A nm-generated is also unsaved + and has no backing file as it is in-memory only.
NM_SETTINGS_CONNECTION_FLAG_VOLATILE	The connection will be deleted -when it disconnects. That is for in-memory connections (unsaved), which are -currently active but deleted on disconnect. Volatile connections are -always unsaved, but they are also no backing file on disk and are entirely -in-memory only. + when it disconnects. That is for in-memory connections (unsaved), which are + currently active but deleted on disconnect. Volatile connections are + always unsaved, but they are also no backing file on disk and are entirely + in-memory only.
NM_ACTIVATION_STATE_FLAG_MASTER_HAS_SLAVES	The master has any slave devices attached. -This only makes sense if the device is a master. + This only makes sense if the device is a master.
NM_ACTIVATION_STATE_FLAG_LIFETIME_BOUND_TO_PROFILE_VISIBILITY	the lifetime -of the activation is bound to the visilibity of the connection profile, -which in turn depends on "connection.permissions" and whether a session -for the user exists. Since: 1.16 + of the activation is bound to the visilibity of the connection profile, + which in turn depends on "connection.permissions" and whether a session + for the user exists. Since: 1.16
NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT	usually, when the connection -has autoconnect enabled and gets added, it becomes eligible to autoconnect -right away. Setting this flag, disables autoconnect until the connection -is manually activated. + has autoconnect enabled and gets added, it becomes eligible to autoconnect + right away. Setting this flag, disables autoconnect until the connection + is manually activated.
NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY	makes the profile in-memory. -Note that such profiles are stored in keyfile format under /run. -If the file is already in-memory, the file in /run is updated in-place. -Otherwise, the previous storage for the profile is left unchanged -on disk, and the in-memory copy shadows it. -Note that the original filename of the previous persistent storage (if any) -is remembered. That means, when later persisting the profile again to disk, -the file on disk will be overwritten again. -Likewise, when finally deleting the profile, both the storage from /run -and persistent storage are deleted (or if the persistent storage does not -allow deletion, and nmmeta file is written to mark the UUID as deleted). + Note that such profiles are stored in keyfile format under /run. + If the file is already in-memory, the file in /run is updated in-place. + Otherwise, the previous storage for the profile is left unchanged + on disk, and the in-memory copy shadows it. + Note that the original filename of the previous persistent storage (if any) + is remembered. That means, when later persisting the profile again to disk, + the file on disk will be overwritten again. + Likewise, when finally deleting the profile, both the storage from /run + and persistent storage are deleted (or if the persistent storage does not + allow deletion, and nmmeta file is written to mark the UUID as deleted).
NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED	this is almost the same -as `NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY`, with one difference: when later deleting -the profile, the original profile will not be deleted. Instead a nmmeta -file is written to /run to indicate that the profile is gone. -Note that if such a nmmeta tombstone file exists and hides a file in persistant -storage, then when re-adding the profile with the same UUID, then the original -storage is taken over again. + as `NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY`, with one difference: when later deleting + the profile, the original profile will not be deleted. Instead a nmmeta + file is written to /run to indicate that the profile is gone. + Note that if such a nmmeta tombstone file exists and hides a file in persistant + storage, then when re-adding the profile with the same UUID, then the original + storage is taken over again.
NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY	this is like `NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY`, -but if the connection has a corresponding file on persistent storage, the file -will be deleted right away. If the profile is later again persisted to disk, -a new, unused filename will be chosen. + but if the connection has a corresponding file on persistent storage, the file + will be deleted right away. If the profile is later again persisted to disk, + a new, unused filename will be chosen.
NM_SETTINGS_UPDATE2_FLAG_VOLATILE	This can be specified with either -`NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY`, `NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED` -or `NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY`. -After making the connection in-memory only, the connection is marked -as volatile. That means, if the connection is currently not active -it will be deleted right away. Otherwise, it is marked to for deletion -once the connection deactivates. A volatile connection cannot autoactivate -again (because it's about to be deleted), but a manual activation will -clear the volatile flag. + `NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY`, `NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED` + or `NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY`. + After making the connection in-memory only, the connection is marked + as volatile. That means, if the connection is currently not active + it will be deleted right away. Otherwise, it is marked to for deletion + once the connection deactivates. A volatile connection cannot autoactivate + again (because it's about to be deleted), but a manual activation will + clear the volatile flag.
NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT	usually, when the connection -has autoconnect enabled and is modified, it becomes eligible to autoconnect -right away. Setting this flag, disables autoconnect until the connection -is manually activated. + has autoconnect enabled and is modified, it becomes eligible to autoconnect + right away. Setting this flag, disables autoconnect until the connection + is manually activated.
NM_SETTINGS_UPDATE2_FLAG_NO_REAPPLY	when a profile gets modified that is -currently active, then these changes don't take effect for the active -device unless the profile gets reactivated or the configuration reapplied. -There are two exceptions: by default "connection.zone" and "connection.metered" -properties take effect immediately. Specify this flag to prevent these -properties to take effect, so that the change is restricted to modify -the profile. Since: 1.20. + currently active, then these changes don't take effect for the active + device unless the profile gets reactivated or the configuration reapplied. + There are two exceptions: by default "connection.zone" and "connection.metered" + properties take effect immediately. Specify this flag to prevent these + properties to take effect, so that the change is restricted to modify + the profile. Since: 1.20.

+++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + +

NM_MANAGER_RELOAD_FLAG_NONE	+ an alias for numeric zero, no flags set. This + reloads everything that is supported and is identical to a SIGHUP. +
NM_MANAGER_RELOAD_FLAG_CONF	+ reload the NetworkManager.conf configuration + from disk. Note that this does not include connections, which can be + reloaded via Setting's `ReloadConnections()`. +
NM_MANAGER_RELOAD_FLAG_DNS_RC	+ update DNS configuration, which usually + involves writing /etc/resolv.conf anew. +
NM_MANAGER_RELOAD_FLAG_DNS_FULL	+ means to restart the DNS plugin. This + is for example useful when using dnsmasq plugin, which uses additional + configuration in /etc/NetworkManager/dnsmasq.d. If you edit those files, + you can restart the DNS plugin. This action shortly interrupts name + resolution. +
NM_MANAGER_RELOAD_FLAG_ALL	+ all flags. +

Since: 1.22

NM_DEVICE_INTERFACE_FLAG_NONE	+ an alias for numeric zero, no flags set. +
NM_DEVICE_INTERFACE_FLAG_UP	+ the interface is enabled from the + administrative point of view. Corresponds to kernel IFF_UP. +
NM_DEVICE_INTERFACE_FLAG_LOWER_UP	+ the physical link is up. Corresponds + to kernel IFF_LOWER_UP. +
NM_DEVICE_INTERFACE_FLAG_CARRIER	+ the interface has carrier. In most + cases this is equal to the value of `NM_DEVICE_INTERFACE_FLAG_LOWER_UP` +. + However some devices have a non-standard carrier detection mechanism. +

enum NMMetered

Members

enum NMManagerReloadFlags

Members

enum NMDeviceInterfaceFlags

Members