From 2e5fa45ddfbb5cffa1e78221f1cea706e2f298af Mon Sep 17 00:00:00 2001
From: Michael Biebl device supports acting as a mesh point
+enum
+NMSettingsAddConnection2Flags
+
+
enum
NMSettingsUpdate2Flags
@@ -507,6 +511,7 @@
├── NMDeviceWifiCapabilities
├── NMSecretAgentCapabilities
├── NMSecretAgentGetSecretsFlags
+ ├── NMSettingsAddConnection2Flags
├── NMSettingsConnectionFlags
╰── NMSettingsUpdate2Flags
@@ -1439,6 +1444,13 @@ GSM/UMTS, or LTE network access protocols
+
+
@@ -1654,6 +1666,13 @@ supported
+
+
+
+
the device is a 802.11s mesh point.
+Numeric flags for the "flags" argument of AddConnection2() D-Bus API.
| + |
+ an alias for numeric zero, no flags set. + |
++ |
| + |
+ to persist the connection to disk. + |
++ |
| + |
+ to make the connection in-memory only. + |
++ |
| + |
+ 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. + |
++ |
Since: 1.20
+to make the connection in-memory only. - If the connection was previously persistent, the corresponding file on disk - is not deleted but merely the connection is decoupled from the file - on disk. If you later delete an in-memory connection, the connection - on disk will be deleted as well.
+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).
this is like NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY
-,
- but if the connection has a corresponding file on disk, the association between
- the connection and the file is forgotten but the file is not modified.
- The difference to NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY is if you later
- save the connection again to disk, a new file name will be chosen without
- overwriting the remaining file on disk. Also, if you delete the connection
- later, the file on disk will not be deleted.
this is almost the same as
this is like NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY
,
- but if the connection has a corresponding file on disk, the file on
- disk will be deleted.
This can be specified with either
- NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED or NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY.
+ 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
@@ -3413,6 +3482,19 @@ VPN plugin authentication dialogs.
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.
+device supports acting as a mesh point
+device supports acting as a mesh point. Since: 1.20.
the device is a 802.11s mesh point.
+the device is a 802.11s mesh point. Since: 1.20.
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
-.
NM_CONNECTION_MULTI_CONNECT_SINGLE.
this is almost the same as
+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.
this is like NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY
-,
+
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.