summaryrefslogtreecommitdiff
path: root/libnm-core
Commit message (Collapse)AuthorAgeFilesLines
* libnm-core: support SAE when determining AP compatibilityBeniamino Galvani2019-09-201-1/+6
| | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/172
* libnm: export reload flagsBeniamino Galvani2019-09-171-0/+28
| | | | | Flags to the manager Reload() method are stable API but not exposed in a public header. Export them.
* setting-gsm: allow empty apn property in verify()Thomas Haller2019-09-112-2/+2
| | | | | | | | | | | | | | | | NetworkManager treats "gsm.apn" %NULL as setting an empty APN (""). At least with ModemManager. With oFono, a %NULL APN means not to set the "AccessPointName", so oFono implementation treats %NULL different from "". Soon the meaning will change to allow %NULL to automatically obtain the APN from the mobile-broadband-provider-info. That will be a change in behavior how to treat %NULL. Anyway, since %NULL is accepted and in fact means to actually use "", the empty word should be also accepted to explicitly choose this behavior. This is especially important in combination with changing the meaning of %NULL.
* setting-gsm: use size_t variable for strlen() resultThomas Haller2019-09-111-5/+6
|
* setting-gsm: add auto-config propertyLubomir Rintel2019-09-113-0/+79
| | | | | | | | | | This will make NetworkManager look up APN, username, and password in the Mobile Broadband Provider database. It is mutually exclusive with the apn, username and password properties. If that is the case, the connection will be normalized to auto-config=false. This makes it convenient for the user to turn off the automatism by just setting the apn.
* core/connection: drop some unused parametersLubomir Rintel2019-09-111-30/+30
|
* all: SPDX header conversionLubomir Rintel2019-09-10143-2101/+143
| | | | | $ find * -type f |xargs perl contrib/scripts/spdx.pl $ git rm contrib/scripts/spdx.pl
* core: fix a typoLubomir Rintel2019-09-031-1/+1
| | | | s/grater/greater/
* keyfile: reorder printing empty [wireguard] section with peers and fix test ↵Thomas Haller2019-09-021-6/+6
| | | | | | | | | | | | | | failure We want to print the [wireguard] section before printing sections of the peers. It just looks nicer. This also fixes a test failure: /libnm/settings/roundtrip-conversion/wireguard/2: ** test:ERROR:./shared/nm-utils/nm-test-utils.h:2254:nmtst_keyfile_assert_data: assertion failed (d1 == data): ("[connection]\nid=roundtrip-conversion-2\nuuid=63376701-b61e-4318-bf7e-664a1c1eeaab\ntype=wireguard\ninterface-name=ifname2\npermissions=\n\n[wireguard-peer.uoGoXWWRxJvu4jDva8pPGA4nxau8B33S+YR+MfPFjxc=]\nendpoint=192.168.255.180:30429\npreshared-key-flags=2\n\n[wireguard-peer.BED73rH9j3OCHYAeXNrW5y5oia/Ngj+M04e9sG7DQOo=]\nendpoint=192.168.188.253:30407\npreshared-key-flags=1\npersistent-keepalive=5070\nallowed-ips=192.168.215.179/32;192.168.120.249/32;a:b:c::e4:13/128;192.168.157.84/32;a:b:c::1b:df/128;a:b:c::b0:84/128;192.168.168.17/32;\n\n[wireguard]\n\n[ipv4]\ndns-search=\nmethod=disabled\n\n[ipv6]\naddr-gen-mode=stable-privacy\ndns-search=\nmethod=ignore\n\n[proxy]\n" == "[connection]\nid=roundtrip-conversion-2\nuuid=63376701-b61e-4318-bf7e-664a1c1eeaab\ntype=wireguard\ninterface-name=ifname2\npermissions=\n\n[wireguard]\n\n[wireguard-peer.uoGoXWWRxJvu4jDva8pPGA4nxau8B33S+YR+MfPFjxc=]\nendpoint=192.168.255.180:30429\npreshared-key-flags=2\n\n[wireguard-peer.BED73rH9j3OCHYAeXNrW5y5oia/Ngj+M04e9sG7DQOo=]\nendpoint=192.168.188.253:30407\npreshared-key-flags=1\npersistent-keepalive=5070\nallowed-ips=192.168.215.179/32;192.168.120.249/32;a:b:c::e4:13/128;192.168.157.84/32;a:b:c::1b:df/128;a:b:c::b0:84/128;192.168.168.17/32;\n\n[ipv4]\ndns-search=\nmethod=disabled\n\n[ipv6]\naddr-gen-mode=stable-privacy\ndns-search=\nmethod=ignore\n\n[proxy]\n") Fixes: ddd148e02b6b ('keyfile: let keyfile writer serialize setting with all default values')
* keyfile: let keyfile writer serialize setting with all default valuesThomas Haller2019-08-272-17/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's important whether a setting is present or not. Keyfile writer omits properties that have a default value, that means, if the setting has all-default values, it would be dropped. For [proxy] that doesn't really matter, because we tend to normalize it back. For some settings it matters: $ nmcli connection add type bluetooth con-name bt autoconnect no bluetooth.type dun bluetooth.bdaddr aa:bb:cc:dd:ee:ff gsm.apn a Connection 'bt' (652cabd8-d350-4246-a6f3-3dc17eeb028f) successfully added. $ nmcli connection modify bt gsm.apn '' When storing this to keyfile, the [gsm] section was dropped (server-side) and we fail an nm_assert() (omitted from the example output below). <error> [1566732645.9845] BUG: failure to normalized profile that we just wrote to disk: bluetooth: 'dun' connection requires 'gsm' or 'cdma' setting <trace> [1566732645.9846] keyfile: commit: "/etc/NetworkManager/system-connections/bt.nmconnection": profile 652cabd8-d350-4246-a6f3-3dc17eeb028f (bt) written <trace> [1566732645.9846] settings: update[652cabd8-d350-4246-a6f3-3dc17eeb028f]: update-from-dbus: update profile "bt" <trace> [1566732645.9849] settings: storage[652cabd8-d350-4246-a6f3-3dc17eeb028f,3e504752a4a78fb3/keyfile]: change event with connection "bt" (file "/etc/NetworkManager/system-connections/> <trace> [1566732645.9849] settings: update[652cabd8-d350-4246-a6f3-3dc17eeb028f]: updating connection "bt" (3e504752a4a78fb3/keyfile) <debug> [1566732645.9857] ++ connection 'update connection' (0x7f7918003340/NMSimpleConnection/"bluetooth" < 0x55e1c52480e0/NMSimpleConnection/"bluetooth") [/org/freedesktop/NetworkManager> <debug> [1566732645.9857] ++ gsm [ 0x55e1c5276f80 < 0x55e1c53205f0 ] <debug> [1566732645.9858] ++ gsm.apn < 'a' Of course, after reload the connection on disk is no loner valid. Keyfile writer wrote an invalid setting. # nmcli connection reload Logfile: <warn> [1566732775.4920] keyfile: load: "/etc/NetworkManager/system-connections/bt.nmconnection": failed to load connection: invalid connection: bluetooth: 'dun' connection requires 'gsm' or 'cdma' setting ... <trace> [1566732775.5432] settings: update[652cabd8-d350-4246-a6f3-3dc17eeb028f]: delete connection "bt" (3e504752a4a78fb3/keyfile) <debug> [1566732775.5434] Deleting secrets for connection /org/freedesktop/NetworkManager/Settings (bt) <trace> [1566732775.5436] dbus-object[9a402fbe14c8d975]: unexport: "/org/freedesktop/NetworkManager/Settings/55"
* keyfile: refactor _parse_info_find() to get ParseInfoSettingThomas Haller2019-08-271-29/+46
| | | | | | | I thought I would need this, but ended up not using it. Anyway, it makes sense in general that the function can lookup all relevant information, so merge it.
* keyfile/tests: add unit test showing bug where keyfile writer looses ↵Thomas Haller2019-08-271-0/+49
| | | | settings that are all-default
* settings/keyfile: check whether profile can be re-read before writing to ↵Thomas Haller2019-08-271-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | disk and fail First of all, keyfile writer (and reader) are supposed to be able to store every profile to disk and re-read a valid profile back. Note that the profile might be modified in the process, for example, blob certificates are written to a file. So, the result might no be exactly the same, but it must still be valid (and should only diverge in expected ways from the original, like mangled certificates). Previously, we would re-read the profile after writing to disk. If that failed, we would only fail an assertion but otherwise proceeed. It is a bug after all. However, it's bad to check only after writing to file, because it results in a unreadable profile on disk, and in the first moment it appears that noting went wrong. Instead, we should fail early. Note that nms_keyfile_reader_from_keyfile() must entirely operate on the in-memory representation of the keyfile. It must not actually access any files on disk. Hence, moving this check before writing the profile must work. Otherwise, that would be a separate bug. Actually, keyfile reader and writer violate this. I added FIXME comments for that. But it doesn't interfere with this patch.
* libnm/doc: improve documentation for NMMetered enum (2)Thomas Haller2019-08-271-10/+10
|
* libnm/doc: improve documentation for NMMetered enumThomas Haller2019-08-261-3/+3
|
* wifi: support WPA2 ad-hoc (ibss-rsn)Beniamino Galvani2019-08-261-24/+8
| | | | | | | | If the device supports it, allow usage of WPA2 in ad-hoc networks. Based-on-patch-by: Nicolas Cavallari <cavallar@lri.fr> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/184
* wifi: drop support for wpa-none key-mgmtBeniamino Galvani2019-08-263-69/+8
| | | | | | | | NM didn't support wpa-none for years because kernel drivers used to be broken. Note that it wasn't even possible to *add* a connection with wpa-none because it was rejected in nm_settings_add_connection_dbus(). Given that wpa-none is also deprecated in wpa_supplicant and is considered insecure, drop altogether any reference to it.
* wifi: expose IBSS_RSN capabilityBeniamino Galvani2019-08-261-0/+2
| | | | | | | The new capability indicates whether the device supports WPA2/RSN in an IBSS (ad-hoc) network. https://bugzilla.gnome.org/show_bug.cgi?id=757823
* libnm: fix NMSetting8021xAuthFlags to be a flags typeThomas Haller2019-08-161-1/+4
| | | | | This is an API break, but probably not too bad. A lot of things when using the type will work as before.
* all: allow configuring default-routes as manual, static routesThomas Haller2019-08-132-20/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Up until now, a default-route (with prefix length zero) could not be configured directly. The user could only set ipv4.gateway, ipv4.never-default, ipv4.route-metric and ipv4.route-table to influence the setting of the default-route (respectively for IPv6). That is a problematic limitation. For one, whether a route has prefix length zero or non-zero does not make a fundamental difference. Also, it makes it impossible to configure all the routing attributes that one can configure otherwise for static routes. For example, the default-route could not be configured as "onlink", could not have a special MTU, nor could it be placed in a dedicated routing table. Fix that by lifting the restriction. Note that "ipv4.never-default" does not apply to /0 manual routes. Likewise, the previous manners of configuring default-routes ("ipv4.gateway") don't conflict with manual default-routes. Server-side this all the pieces are already in place to accept a default-route as static routes. This was done by earlier commits like 5c299454b49b ('core: rework tracking of gateway/default-route in ip-config'). A long time ago, NMIPRoute would assert that the prefix length is positive. That was relaxed by commit a2e93f2de4ac ('libnm: allow zero prefix length for NMIPRoute'), already before 1.0.0. Using libnm from before 1.0.0 would result in assertion failures. Note that the default-route-metric-penalty based on connectivity checking applies to all /0 routes, even these static routes. Be they added due to DHCP, "ipv4.gateway", "ipv4.routes" or "wireguard.peer-routes". I wonder whether doing that unconditionally is desirable, and maybe there should be a way to opt-out/opt-in for the entire profile or even per-routes. https://bugzilla.redhat.com/show_bug.cgi?id=1714438
* libnm: avoid heap allocation for checking valid routes in ↵Thomas Haller2019-08-131-11/+14
| | | | nm_ip_route_attribute_validate()
* libnm: set errno in nm_key_file_get_boolean() to distinguish between missing ↵Thomas Haller2019-08-131-3/+13
| | | | | | | key and error This is also what nm_keyfile_plugin_kf_get_int64() does. It's useful to know whether a value was missing or invalid.
* libnm/doc: fix typoThomas Haller2019-08-121-1/+1
|
* libnm/doc: clarify NMMetered enum and how metered state in NetworkManager worksThomas Haller2019-08-121-0/+27
|
* shared,all: return boolean success from nm_utils_file_get_contents()Thomas Haller2019-08-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | ... and nm_utils_fd_get_contents() and nm_utils_file_set_contents(). Don't mix negative errno return value with a GError output. Instead, return a boolean result indicating success or failure. Also, optionally - output GError - set out_errsv to the positive errno (or 0 on success) Obviously, the return value and the output arguments (contents, length, out_errsv, error) must all agree in their success/failure result. That means, you may check any of the return value, out_errsv, error, and contents to reliably detect failure or success. Also note that out_errsv gives the positive(!) errno. But you probably shouldn't care about the distinction and use nm_errno_native() either way to normalize the value.
* libnm/doc: add missing "Since: 1.20" commentsThomas Haller2019-08-063-3/+5
|
* libnm/doc: add Since tag for %NM_SETTING_IP6_CONFIG_METHOD_DISABLEDThomas Haller2019-08-061-0/+2
|
* libnm-core: fix ifcfg-rh variable name for DHCPv6 hostnameBeniamino Galvani2019-08-051-1/+1
| | | | Fixes: 2852b509456d ('ifcfg-rh: add DHCPV6_HOSTNAME and DHCPV6_SEND_HOSTNAME vars')
* libnm: when stringifying policy routing rule place "not" specifier after ↵Thomas Haller2019-08-052-5/+8
| | | | | | | | | | | | | | | | | | "priority" Otherwise, it just looks odd: "not priority 31265 from 0.0.0.0/0 fwmark 0xcb87 table 52103" Better is: "priority 31265 not from 0.0.0.0/0 fwmark 0xcb87 table 52103" The "not" specifier should come after the priority. It makes more sense to read it that way. As far as parsing the string is concerned, the order does not matter. So this change in behavior is no problem. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/228
* libnm: fix leak in NMSettingWireGuard's update_one_secret()Thomas Haller2019-08-031-1/+1
|
* libnm: remove dead code in nm_team_setting_config_get()Thomas Haller2019-08-021-2/+2
| | | | | | | I was aware that this code is not reachable. But for consistency, it seems better to be explict about it (to avoid future bugs when refactoring). Anyway, Coverity complains about it. So assert instead.
* libnm: fix parsing invalid "pvid" attribute in GVariant in ↵Thomas Haller2019-08-021-2/+4
| | | | | | _nm_utils_bridge_vlans_from_dbus() Complained by Coverity.
* libnm/keyfile: silence "Identical code for different branches" complaint in ↵Thomas Haller2019-08-021-4/+3
| | | | | | | _read_setting_wireguard_peer() That both branches of the "if" do the same, looks suspicious to Coverity. Work around it by not doing it.
* libnm: avoid NM_CONST_MAX() in enum definition for NMTeamAttributeThomas Haller2019-08-021-1/+1
| | | | | | | | | This confuses coverity. Just use MAX(). MAX() is usually not preferred as it evaluates the arguments more than once. But in this case, it is of course fine. CID 202433 (#1 of 1): Unrecoverable parse warning (PARSE_ERROR)1. expr_not_constant: expression must have a constant value
* libnm: try to avoid coverity warning in assertion()Thomas Haller2019-08-021-1/+1
| | | | | Coverity thinks that this could be NULL sometimes. Try to check for that to shut up the warning.
* libnm: fix assertions in NMSettingVlan's priority APIThomas Haller2019-08-021-20/+21
| | | | | | | | | | | | Most of these functions did not ever return failure. The functions were assertin that the input was valid (and then returned a special value). But they did not fail under regular conditions. Fix the gtk-doc for some of these to not claim to be able to fail. For some (like nm_setting_vlan_add_priority_str() and nm_setting_vlan_get_priority()), actually let them fail for valid input (instead of asserting).
* libnm/doc: fix gtk-doc annotations for documenting enum values in ↵Thomas Haller2019-07-301-4/+4
| | | | "nm-dbus-interface.h"
* release: bump version to 1.21.0 (development)1.21.0-devThomas Haller2019-07-291-0/+14
|
* wireguard: support configuring policy routing to avoid routing loopsThomas Haller2019-07-293-1/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of the peers must be reached outside the tunnel/VPN itself. For VPN connections, NetworkManager usually adds a direct /32 route to the external VPN gateway to the underlying device. For WireGuard that is not done, because injecting a route to another device is ugly and error prone. Worse: WireGuard with automatic roaming and multiple peers makes this more complicated. This is commonly a problem when setting the default-route via the VPN, but there are also other subtle setups where special care must be taken to prevent such routing loops. WireGuard's wg-quick provides a simple, automatic solution by adding two policy routing rules and relying on the WireGuard packets having a fwmark set (see [1]). Let's also do that. Add new properties "wireguard.ip4-auto-default-route" and "wireguard.ip6-auto-default-route" to enable/disable this. Note that the default value lets NetworkManager automatically choose whether to enable it (depending on whether there are any peers that have a default route). This means, common scenarios should now work well without additional configuration. Note that this is also a change in behavior and upon package upgrade NetworkManager may start adding policy routes (if there are peers that have a default-route). This is a change in behavior, as the user already clearly had this setup working and configured some working solution already. The new automatism picks the rule priority automatically and adds the default-route to the routing table that has the same number as the fwmark. If any of this is unsuitable, then the user is free to disable this automatism. Note that since 1.18.0 NetworkManager supports policy routing (*). That means, what this automatism does can be also achieved via explicit configuration of the profile, which gives the user more flexibility to adjust all parameters explicitly). (*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength" rule attribute, which makes it impossible to configure exactly this rule-based solution with 1.18.0 NetworkManager. [1] https://www.wireguard.com/netns/#improved-rule-based-routing
* libnm: add internal _nm_connection_get_setting() accessorThomas Haller2019-07-291-0/+7
| | | | | | | | | | | | | | | | | nm_connection_get_setting() returns a pointer of type NMSetting. That is very inconvenient, because most callers will need the the result pointer as a setting subtype (like NMSettingConnection). That would be like g_object_new() returning a "GObject *" pointer, which is technically correct but annoying. In the past that problem was avoided by having countless accessors like nm_connection_get_setting_ip4_config(), etc. But that just blows up the API and also is not generic. Meaning: the type is not a function argument but the function itself. That makes composing the code harder as the setting type cannot be treated generically (as a function argument). Anyway. Add an internal wrapper that returns a void pointer.
* libnm/docs: fix section description for WireGuard settingsThomas Haller2019-07-291-1/+1
|
* man: setting-wireless: add "mesh" to the available modesFrancesco Giudici2019-07-291-1/+1
|
* libnm-core: add nm_utils_wifi_freq_to_bandAndy Kling2019-07-292-0/+21
| | | | | | | allow to retrieve wifi band from frequency. [lkundrak@v3.sk: formatting fixes, move the prototype to a private header]
* libnm-core: 802-11-wireless.mode mesh requires band and channelAndy Kling2019-07-291-0/+10
| | | | | | | | an essential feature of 802.11s is to allow moving/mobile mesh points and adapt the topology dynamically. This includes starting a mesh point not in range of others and establish the connection once it comes into range. At the moment for this reason a mesh connection requires the frequency to be fixed as supplicant does too.
* wireless-security: ensure Mesh networks can't use anything but SAELubomir Rintel2019-07-291-8/+26
| | | | They must be either open or use SAE key management.
* setting-wireless: allow Mesh modeLubomir Rintel2019-07-292-1/+14
|
* dbus-interface: add Mesh supportLubomir Rintel2019-07-291-0/+4
| | | | Add flags that indicate Mesh support and Mesh mode on a device.
* settings: track profiles on disk that are shadowed by in-memory connectionsThomas Haller2019-07-251-18/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Via Update2() D-Bus API there are three ways how a profile can be stored (or migrated) to in-memory: - NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY - NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED - NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY With the recent rework of settings I dropped NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY and it had the same meaning as NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED. However, the way NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED was implemented is problematic. The problem is that it leaves the profile on disk but creates an in-memory representation which shadows the persistent storage. Later, when storing the profile to disk again, a new filename is chosen. This allows via D-Bus API to toggle between NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED and NM_SETTINGS_UPDATE2_FLAG_TO_DISK, and thereby pilling up profiles on disk. Also, there is no D-Bus API to do anything sensible with these leaked, shadowed profiles on disk. Note that if we have a read-only profile in /usr/lib or in ifupdown plugin, then the problem is not made any worse. That is, because via D-Bus API such profiles can be made in-memory, and afterwards stored to /etc. Thereby too the profile gets duplicate on disk, but this game only works once. Afterwards, you cannot repeat it to create additional profiles on disk. It means, you can only leak profiles once, and only if they already exist in read-only storage to begin with. This problem with NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED already existed before the settings-delegate-storage rework, and is unrelated to whether in-memory profiles now happen to be persisted to /run. Note that NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY is simple and does not suffer from this problem. When you move a profile to in-memory-only, it gets deleted from persistent storage and no duplication happens. The problem is that NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED used to forget about the profile that it shadows, and that is wrong. So, first re-add proper support for NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY. This works by remembering the "shadowed-storage" path for in-memory profiles. When later saving such a profile to disk again, the shadowed-storage will be re-used. Likewise, when deleting such a profile, the shadowed storage will be deleted. Note that we keep NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED and it also remembers the shadowed storage (but without "owning" it). That means, when such a profile gets saved to disk again, the orginal storage is reused too. As such, during future updates it behaves just like NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY. The difference is when deleting such a profile. In this case, the profile is left on storage and a tombstone gets written. So, how is this better than before and why even keep this complicated flag? First, we keep this flag because we really want the ansible role to be able to do in-memory changes only. That implies being able to delete a profile from NetworkManager's view, but not from persistent storage. Without this flag there is no way to do that. You can only modify an on-disk profile by shadowing it, but you could not delete it form NetworkManager's view while keeping it on disk. The new form of NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACHED is safe and avoids the duplication problem because also for tombstones it remembers the original "shadowed-storage". That is, when the profile gets recreated later via D-Bus API AddConnection, then the re-created profile will still reference and reuse the shadowed storage that it had before deletion.
* settings: support storing "shadowed-storage" to [.nmmeta] section for ↵Thomas Haller2019-07-251-0/+2
| | | | | | | | | | | | | | | | | | keyfiles in /run When we make runtime only changes, we may leave the profile in persistent storage and store a overlay profile in /run. However, in various cases we need to remember the original path. Add code to store and retrieve that path from the keyfile. Note that this data is written inside the keyfile in /run. That is because this piece of information really depends on that particular keyfile, and not on the profile/UUID. That is why we write it to the [.nmmeta] section of the keyfile and not to the .nmmeta file (which is per-UUID). This patch only adds the backend to write and load the setting from disk. It's not yet used.
* core,libnm: add AddConnection2() D-Bus API to block autoconnect from the startThomas Haller2019-07-251-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It should be possible to add a profile with autoconnect blocked form the start. Update2() has a %NM_SETTINGS_UPDATE2_FLAG_BLOCK_AUTOCONNECT flag to block autoconnect, and so we need something similar when adding a connection. As the existing AddConnection() and AddConnectionUnsaved() API is not extensible, add AddConnection2() that has flags and room for additional arguments. Then add and implement the new flag %NM_SETTINGS_ADD_CONNECTION2_FLAG_BLOCK_AUTOCONNECT for AddConnection2(). Note that libnm's nm_client_add_connection2() API can completely replace the existing nm_client_add_connection_async() call. In particular, it will automatically prefer to call the D-Bus methods AddConnection() and AddConnectionUnsaved(), in order to work with server versions older than 1.20. The purpose of this is that when upgrading the package, the running NetworkManager might still be older than the installed libnm. Anyway, so since nm_client_add_connection2_finish() also has a result output, the caller needs to decide whether he cares about that result. Hence it has an argument ignore_out_result, which allows to fallback to the old API. One might argue that a caller who doesn't care about the output results while still wanting to be backward compatible, should itself choose to call nm_client_add_connection_async() or nm_client_add_connection2(). But instead, it's more convenient if the new function can fully replace the old one, so that the caller does not need to switch which start/finish method to call. https://bugzilla.redhat.com/show_bug.cgi?id=1677068
View Lorry Controller Status