If the file was read-only, we already closed it.
This fixes the following valgrind warnings:
Warning: invalid file descriptor -1 in syscall close()
(cherry picked from commit 174da8f922)
If the tracked device is a control device only (has no network interface)
like in the case of a cdc-wdm device, get the mtu from the ip interface
(the exposed wwan network interface in this case).
https://bugzilla.redhat.com/show_bug.cgi?id=1460217
(cherry picked from commit efed5254cd)
/proc/sys might be read-only but we want to set it for
enabling shared mode.
Check first if the sysctl already has the expected value,
and if so, do nothing.
https://bugzilla.gnome.org/show_bug.cgi?id=790726
(cherry picked from commit d841930d67)
Also downgrade a few intermediate error logging messages
for failures that happen while start_sharing(). A debug
message is enough in this case, because we propagate now
the error to the caller, which logs a warning anyway.
(cherry picked from commit 3369a2c0b0)
We should use the same str2bool parser everywhere: _nm_utils_ascii_str_to_bool().
Incidentally, this function allows more forms of expressing a boolean
value.
$ nmcli connection modify "$CON" ipv4.routes '1.2.3.4/32 1.2.3.1 onlink=1'
Error: failed to modify ipv4.routes: invalid option 'onlink=1': invalid boolean value '1' for attribute 'onlink'.
(cherry picked from commit 26e7abc65e)
We cannot just call g_object_set() with an integer that is out of bound.
Otherwise, glib will warn. We can use nm_g_object_set_property*() to return
an error without asserting.
(cherry picked from commit ff239c1652)
Currently both bridge.mac-address and ethernet.cloned-mac-address get
written to the same MACADDR ifcfg-rh variable; the ethernet property
wins if both are present.
When one property is set and the connection is saved (and thus reread)
both properties are populated with the same value. This is wrong
because, even if the properties have the same meaning, the setting
plugin should not read something different from what was written. Also
consider that after the following steps:
$ nmcli con mod c ethernet.cloned-mac-address 00:11:22:33:44:55
$ nmcli con mod c ethernet.cloned-mac-address ""
the connection will still have the new mac address set in the
bridge.mac-address property, which is certainly unexpected.
In general, mapping multiple properties to the same variable is
harmful and must be avoided. Therefore, let's use a different variable
for bridge.mac-address. This changes behavior, but not so much:
- connections that have MACADDR set will behave as before; the only
difference will be that the MAC will be present in the wired
setting instead of the bridge one;
- initscripts compatibility is not relevant because MACADDR for
bridges was a NM extension;
- if someone creates a new connection and sets bridge.mac-address NM
will set the BRIDGE_MACADDR property instead of MACADDR. But this
shouldn't be a big concern as bridge.mac-address is documented as
deprecated and should not be used for new connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1516659
(cherry picked from commit fb191fc282)
Since the order was arbitrary before, we can also sort it.
Also rework it, to avoid the creating a temporary GList of keys.
(cherry picked from commit d5b3c6ee53)
It is common to have some data indexed by a name.
If you want to sort a list of such data, you would
have to re-implement your own compare function each time.
Instead, add NMUtilsNamedEntry which as first field has
the name. So, you can create your own struct:
struct my_data {
const char *name;
... other fields
}
and compare them with with nm_utils_named_entry_cmp().
For convenience, add another struct NMUtilsNamedValue, which
has only one data field, a pointer.
(cherry picked from commit 3adce12898)
Settings plugins now return the connection that was reread from file
when adding a connection, which means that any agent-owned secret is
lost. Ensure that we don't forget agent-owned secrets by caching them
and readding them to the new connection returned by plugins.
Fixes: 8a1d483ca8
Fixes: b4594af55ehttps://bugzilla.gnome.org/show_bug.cgi?id=789383
(cherry picked from commit 62141d59cb)
Bond options are stored in a hash table and the order in which they
are returned by the API is not guaranteed. Sort them alphabetically so
that a connection will always be written in the same way, even if the
internal implementation of the hash table or the hashing function
changes, as it did in commit a6be2f4aa9 ("all: use nm_str_hash()
instead of g_str_hash()").
(cherry picked from commit 9a631a068e)
Matters when backslash escaping ascii charaters <= 0xF, to
produce "\\XX" instead of "\\ X". For example tabulator is "\\09".
This also can trigger an nm_assert() failure, when building with
--with-more-asserts=5 (or higher).
(cherry picked from commit 89c89143b5)
check_and_add_ipv6ll_addr() checks whether a link-local address is
already present in priv->ip6_config and if so, it returns with no
action.
priv->ip6_config is only updated after a merge-and-apply or (in an
idle source) when the external configuration changes and so there is
no guarantee that the addresses there are up-to-date.
priv->ext_ip6_config_captured should be checked instead, because it is
updated from platform right before starting the generation of a
link-local address. Note that also linklocal6_start() already checks
the captured external configuration rather than priv->ip6_config.
https://bugzilla.redhat.com/show_bug.cgi?id=1500350
(cherry picked from commit a7c97d58db)
Fix resolved detection, the symlink target is usually relative to the
root, such that in chroots the file points to a file inside the
chroot. But keep absolute targets too, as these may have been in use
with older version of systemd. Add support for stub-resolv.conf
detection.
https://bugzilla.gnome.org/show_bug.cgi?id=790446
(cherry picked from commit e09503dcc4)
If a device is 'external' (which means that NM generated an in-memory
connection to only to track the device state) we should not change its
IP configuration.
https://bugzilla.redhat.com/show_bug.cgi?id=1512316
(cherry picked from commit 60334a2893)
In the next commit we will modify ipX_config_merge_and_apply to never
touch external devices. When a "reapply" call is issued on an external
device we are no longer simply tracking its state but we are actively
managing it and so its sys-iface-state must be promoted to managed.
https://bugzilla.redhat.com/show_bug.cgi?id=1512316
(cherry picked from commit 9e41ed4461)
Don't reset existing routes if ipvx.ignore-auto-routes=yes: callers
should already avoid adding them when not needed.
Previously we would also reset the manual gateway route just added.
Fixes: 5c299454b4https://bugzilla.gnome.org/show_bug.cgi?id=790423
(cherry picked from commit a0cd75b20c)
Instead of adding routes and then let nm_ipx_config_merge_setting()
remove them, don't add them in the first place when
ipvx.ignore-auto-routes=yes.
(cherry picked from commit 8f677a7772)
