If a volatile connection is deleted by user when it was already being
deleted internally because the device vanished, we may hit the
following failed assertion:
file src/settings/nm-settings-connection.c: line 2196
(nm_settings_connection_signal_remove): should not be reached
The @removed flag keeps track of whether we already signaled the
connection removal. Instead of throwing an assertion if we try to emit
the signal again, just return without action because this can happen
in the situation described above.
While at it, remove the @allow_reuse argument from
nm_settings_connection_signal_remove(): we should never emit the
signal twice. Instead, we should reset the @removed flag when the
connection is added.
Fixes: a9384452edhttps://bugzilla.redhat.com/show_bug.cgi?id=1506552
(cherry picked from commit 98ac0f404e)
First check that the limit of 50 metric points is not surpassed.
Otherwise, if you have an ethernet device (aspired 100, effective
130) and a MACSec devic (aspired 125, effective 155), activating a
new ethernet device would bump it's metric to 155 -- more then
the 50 points limit.
It doesn't matter too much, because the cases where the limit of
50 could have been surpassed were very specific. Still, change
it to ensure that the limit is always honored as one would expect.
Fixes: 6a32c64d8f
(cherry picked from commit 2499d3bdc6)
In the past we had NMDefaultRouteManager which would coordinate adding
the default-route with identical metrics. That especially happened, when
activating two devices of the same type, without explicitly specifying
ipv4.route-metric. For example, with ethernet devices, the routes on
both interfaces would get a metric of 100.
Coordinating routes was especially necessary, because we added
routes with NLM_F_EXCL flag, akin to `ip route replace`. We not
only had to avoid that activating two devices in NetworkManager would
result in a fight over the default-route, but more importently
to preserve externally added default-routes on unmanaged interfaces.
NMDefaultRouteManager would ensure that in case of duplicate
metrics, that the device that activated first would keep the
best default-route. It would do so by bumping the metric
of the second device to find a unused metric. The bumping itself
was not very important -- MDefaultRouteManager could also just not
configure any default-routes that show up as second, the result
would be quite similar. More important was to keep the best
default-route on the first activating device until the device
deactivates or a device activates that really has a better
default-route..
Likewise, NMRouteManager would globally manage non-default-routes.
It would not do any bumping of metrics, but it would also ensure that the routes
of the device that activates first are not overwritten by a device activating
later.
However, the `ip route replace` approach has downsides, especially
that it messes with routes on other interfaces, interfaces that are
possibly not managed by NetworkManager. Another downside is, that
binding a socket to an interface might not result in correct
routes, because the route might just not be there (in case of
NMRouteManager, which wouldn't configure duplicate routes by bumping
their metric).
Since commit 77ec302714 we would no longer
use NLM_F_EXCL, but add routes akin to `ip route append`. When
activating for example two ethernet devices with no explict route
metric configuration, there are two routes like
default via 10.16.122.254 dev eth0 proto dhcp metric 100
default via 192.168.100.1 dev eth1 proto dhcp metric 100
This does not only affect default routes. In case of a multi-homing
setup you'd get
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100
192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100
but it's visible the most for default-routes.
Note that we would append the routes that are activated later, as the order
of `ip route show` confirms. One might hence expect, that kernel selects
a route based on the order in the routing tables. However, that isn't
the case, and activating the second interface will non-deterministically
re-route traffic via the new interface. That will interfere badly with
with NAT, stateful firewalls, and existing connections (like TCP).
The solution is to have NMManager keep a global index of the default route-metrics
currently in use. So, instead of determining the default-route metric based solely
on the device-type, we now in addition generate default metrics that do not
overlap. For example, if you activate eth0 first, it gets route-metric 100,
and if you then activate eth1, it gets 101. Note that if you deactivate
and re-activate eth0, then it will get route-metric 102, because the
best route should stick on eth1 (which reserves the range 100 to 101).
Note that when a connection explititly selects a particular metric, then that
choice is honored (contrary to NMDefaultRouteManager which was more concerned
with avoiding conflicts, then keeping the exact metric).
https://bugzilla.redhat.com/show_bug.cgi?id=1505893
(cherry picked from commit 6a32c64d8f)
NMManager will need to know the state of all device at once.
Hence, load it once and cache it in NMConfig.
Note that this wastes a bit of memory in the order of
O(number-of-interfaces). But each device state entry is
rather small, and we always consume memory in the order
of O(number-of-interfaces).
(cherry picked from commit ea08df925f)
@kind might be NULL. There are 3 forms of the hash-update functions for
string: str(), str0(), and strarr().
- str0() is when the string might be NULL.
- str() does not allow the string to be NULL
- strarr() is like str(), except it adds a G_STATIC_ASSERT()
that the argument is a C array.
The reason why a difference between str() and str0() exists, is
because str0() hashes NULL different from a "" or any other string.
This has an overhead, because it effectively must hash another bit
of information that tells whether a string was passed or not.
The reason is, that hashing a tupple of two strings should always
yield a different hash value, even for "aa",""; "a","a"; "","aa",
where naive concatentation would yield identical hash values in all
three cases.
Fixes: e75fc8279b
(cherry picked from commit 27e8fffdb8)
It's not critical, because at worst we get a false-positive that
something changed.
Found by coverity.
Fixes: 4e7b05de79
(cherry picked from commit fbc6008260)
We're going to need that one for TC filter & action support.
<linux/tc_act/tc_defact.h> was moved to user-space API only in 2013
by commit 5bc3db5c9ca8407f52918b6504d3b27230defedc. Our travis CI currently
fails to build due to that.
Re-implement the header.
(cherry picked from commit 82befe3c40)
It only makes sense to call delete() with NMPObjects that
we obtained from the platform cache. Otherwise, if we didn't
get it from the cache in the first place, we wouldn't know
what to delete.
Hence, the input argument is (almost) always an NMPObject
in the first place. That is different from add(), where
we might create a new specific NMPlatform* instance on the
stack. For add() it makes slightly more sense to have different
functions depending on the type. For delete(), it doesn't.
(cherry picked from commit 7573594a21)
There are a few cases where we don't want to clear a potential
nm-generated/volatile flag, but only mark the connection as
unsaved.
Otherwise, we wrongly end up clearing these flags and the connection
is wrongly not NM_DEVICE_SYS_IFACE_STATE_EXTERNAL.
Fixes: 35dc6421de
(cherry picked from commit 7044febf97)
DNS searches from the ipv4 and ipv6 settings were joined and written
to the same ifcfg-rh "DOMAIN" variable and so the connection read back
from disk was different from the one written.
Instead, introduce a separate variable for ipv6 searches; to preserve
backwards compatibility, still read the "DOMAIN" variable for ipv6
when ipv4 is disabled so that we don't lose DNS searches on upgrade.
https://bugzilla.redhat.com/show_bug.cgi?id=1517794
(cherry picked from commit a9b5079324)
This is now required as we instance inotify-helper only on need:
we have to init them to the unset value, otherwise...
Thread 1 "NetworkManager" received signal SIGSEGV, Segmentation fault.
nm_inotify_helper_remove_watch (self=0x0, wd=0) at src/settings/plugins/ifcfg-rh/nm-inotify-helper.c:100
100 if (priv->ifd < 0)
(gdb) backtrace
#0 0x00007fffe35da6c0 in nm_inotify_helper_remove_watch (self=0x0, wd=0) at src/settings/plugins/ifcfg-rh/nm-inotify-helper.c:100
#1 0x00007fffe35d45b1 in nm_inotify_helper_clear_watch (wd=0x7fffdc008628, helper=<optimized out>) at src/settings/plugins/ifcfg-rh/nm-inotify-helper.h:53
#2 0x00007fffe35d45b1 in path_watch_stop (self=0x7fffdc0085f0) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-connection.c:223
#3 0x00007fffe35d467c in filename_changed (object=0x7fffdc0085f0, pspec=<optimized out>, user_data=<optimized out>) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-connection.c:242
#4 0x00007ffff61b230d in g_closure_invoke () at /lib64/libgobject-2.0.so.0
#5 0x00007ffff61c498e in signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#6 0x00007ffff61cd1a5 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#7 0x00007ffff61cdb0f in g_signal_emit () at /lib64/libgobject-2.0.so.0
#8 0x00007ffff61b6594 in g_object_dispatch_properties_changed () at /lib64/libgobject-2.0.so.0
#9 0x00007ffff61b5f3e in g_object_notify_queue_thaw () at /lib64/libgobject-2.0.so.0
#10 0x00007ffff61b7776 in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#11 0x00007ffff61b924d in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#12 0x00007ffff61b9691 in g_object_new () at /lib64/libgobject-2.0.so.0
#13 0x00007fffe35d5018 in nm_ifcfg_connection_new (source=source@entry=0x0, full_path=full_path@entry=0x555555a9a590 "/etc/sysconfig/network-scripts/ifcfg-team3", error=error@entry=0x7fffffffdc30, out_ignore_error=out_ignore_error@entry=0x7fffffffdc2c) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-connection.c:429
#14 0x00007fffe35d5e96 in update_connection (self=self@entry=0x555555a59ea0, source=source@entry=0x0, full_path=0x555555a9a590 "/etc/sysconfig/network-scripts/ifcfg-team3", connection=connection@entry=0x0, protect_existing_connection=protect_existing_connection@entry=0, protected_connections=protected_connections@entry=Python Exception <class 'gdb.error'> There is no member named keys.:
0x555555a9fc00, error=0x0) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c:218
#15 0x00007fffe35d7073 in read_connections (plugin=plugin@entry=0x555555a59ea0) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c:545
#16 0x00007fffe35d72f1 in get_connections (config=0x555555a59ea0) at src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-plugin.c:581
#17 0x00005555556bb513 in load_connections (self=0x555555a1a920) at src/settings/nm-settings.c:239
#18 0x00005555556bb513 in nm_settings_start (self=0x555555a1a920, error=<optimized out>) at src/settings/nm-settings.c:1800
#19 0x00005555555ada1f in nm_manager_start (self=0x555555a490c0, error=<optimized out>) at src/nm-manager.c:5262
#20 0x00005555555851ae in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:417
Fixes: 31f2a46639
(cherry picked from commit 993a726c4a)
When building with assertions, they nm_assert() for the
type. Otherwise, they are identical to a C cast.
Also, where possible, don't cast at all, but adjust
the type instead.
Also, there were a few missing casts.
(cherry picked from commit 7661ad64ba)
Extend the Update2 flags to allow marking a connection as volatile.
Making a connection as volatile means that the connection stays alive
as long as an active connection references it.
It is correct that Update2() returns before the connection is actually
deleted. It might take an arbitrary long time until the volatile
mechanism cleans up the connection.
Also add two more IN_MEMORY flags: "detached" and "only".
The existing NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY would not detach nor
delete the possible file on disk. That is, the mode only changes what NM
thinks is the current content of the connection profile. It would not delete
the file on disk nor would it detach the profile in-memory from the file.
As such, later persisting the connection again to disk would overwrite
the file, and deleting the profile, would delete the file.
Now add two new IN_MEMORY modes.
NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_DETACH is like making the connection
in-memory only, but forgetting that there might be any profile on disk.
That means, a later Delete() would not delete the file. Similarly, a
later Update2() that persists the connection again, would not overwrite
the existing file on disk, instead it would choose a new file name.
On the other hand, NM_SETTINGS_UPDATE2_FLAG_IN_MEMORY_ONLY would delete
a potential file from disk right away.
It's clear that "volatile" only makes sense with either "in-memory-detached"
or "in-memory-only". That is, the file on disk should be deleted right away
(before the in-memory part is garbage collected) or the file on disk should
be forgotten.
(cherry picked from commit 35dc6421de)
Previously, we would only set a connection as volatile before
adding it to manager. As we never would set it volatile last on,
there was no need to handle deletion.
Now support that. Watch the volatile flag, and if the connection
has currently not active connection that keeps it alive, delete
it in an idle handler.
(cherry picked from commit cfced599ca)
First, define structs. Then forward declare functions. Reorder code
to have a certain order that is also used by other files (or should
be).
(cherry picked from commit 4c84f74326)
Previously, NMPolicy would explicitly check whether the connection is not visible,
to skip autoconnect.
We have nm_settings_connection_autoconnect_is_blocked() function, that can do that.
The advantage is, that at various places we call nm_settings_connection_autoconnect_is_blocked()
to determine whether autoconnect is blocked. By declaring invisible connections
as blocked from autoconnect as well, we short-cut various autoconnection attempts,
that previoulsy only failed later during auto_activate_device().
(cherry picked from commit ccc93639a0)
The accessor functions just look whether a certain flag is set. As these
functions have a different name then the flags, this is more confusing
then helpful. For example, if you want to know where the NM_GENERATED
flag matters, you had to know to grep for nm_settings_connection_get_nm_generated()
in addition to NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED.
The accessor function hid that the property was implemented as
a connection flag. For example, it was not immediately obvious
that nm_settings_connection_get_nm_generated() is the same
as having the NM_SETTINGS_CONNECTION_FLAGS_NM_GENERATED flag
set.
Drop them.
(cherry picked from commit 545e3111c8)
It seems more idiomatic to have a mask+value argument, instead
of setting all flags at once. At least, other setters work this
way, so change it for consistency.
(cherry picked from commit 4549bd07a1)
We already need to re-emit the notify::flags signal.
It's cumbersome to do this for boolean properties, so
re-use the flags to also track the visibility state.
(cherry picked from commit 0e1abe5ef3)
