The test tries to do IPv4 DAD. That necessarily involves waiting
for a timeout. Since the NMArpingManager spawns arping processes,
the precise timings depend on the load of the machine and may be
large in some cases.
Usually, our test would run fast to successful completion.
However, sometimes, it can take several hundered milliseconds.
Instead of increasing the timeout to a large value (which would
needlessly extend the run time of our tests in the common cases),
try first with a reasonably short timeout. A timeout which commonly
results in success. If the test with the short timeout fails, just
try again with an excessively large timeout.
This saves about 400 msec for the common case, but extends the
races that we saw where not even 250 msec of wait time were
sufficient.
(cherry picked from commit 059d34a27f)
If an operation is cancelled through the GCancellable, then the idiom is
that the operation is always cancelled, even if it has finished
successfully. To ensure this is the case, add calls to
g_simple_async_result_set_check_cancellable everywhere.
Without this, e.g. gnome-control-center will crash when switching away
from the power panel quickly, as the NMClient creation finishes
asynchronously and g-c-c assume that G_IO_ERROR_CANCELLED is returned to
ensure it doesn't access the now invalid user_data parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=794088
(cherry picked from commit 26c215e22d)
The condition was obviosly inverted, blocking autoconnect when
it should not, and not blocking it when it should.
[thaller@redhat.com: modified original patch and rewrite commit message]
Fixes: e2c8ef45achttps://bugzilla.gnome.org/show_bug.cgi?id=794014
(cherry picked from commit d2f019409d)
IPv4 routes that are a response to RTM_GETROUTE must have the cloned
flag while IPv6 routes don't have to. Don't check the flag for IPv6
routes and add a test case to verify that RTM_GETROUTE works for IPv6.
https://bugzilla.gnome.org/show_bug.cgi?id=793962
(cherry picked from commit 2d1fad641b)
The error should be freed by callback functions, but only
_monitor_bridges_cb() actually does it. Simplify this by letting the
caller own the error.
Fixes: 830a5a14cb
(cherry picked from commit 878a3a4125)
When NM quits it destroys all singletons including NMOvsdb, which
invokes callbacks for every pending method call. In the shutdown,
extra care must be taken to not access objects that are already in a
inconsistent state; for example here, the callback changes the device
state, and this causes an access to data that has already been
cleared:
#0 _g_log_abort (breakpoint=breakpoint@entry=1) at gmessages.c:554
#1 g_logv (log_domain=0x5635653b6817 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffb4b2c1e0) at gmessages.c:1362
#2 g_log (log_domain=log_domain@entry=0x5635653b6817 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7fbb3f58fa4a "%s: assertion '%s' failed") at gmessages.c:1403
#3 g_return_if_fail_warning (log_domain=log_domain@entry=0x5635653b6817 "NetworkManager", pretty_function=pretty_function@entry=0x5635653b6b00 <__func__.34463> "nm_device_factory_manager_find_factory_for_connection", expression=expression@entry=0x5635653b6719 "factories_by_setting") at gmessages.c:2702
#4 nm_device_factory_manager_find_factory_for_connection (connection=connection@entry=0x56356627e0e0) at src/devices/nm-device-factory.c:243
#5 nm_manager_get_connection_iface (self=0x563566241080 [NMManager], connection=connection@entry=0x56356627e0e0, out_parent=out_parent@entry=0x0, error=error@entry=0x0) at src/nm-manager.c:1458
#6 check_connection_compatible (self=<optimized out>, connection=0x56356627e0e0) at src/devices/nm-device.c:4679
#7 check_connection_compatible (device=0x56356647b1b0 [NMDeviceOvsInterface], connection=0x56356627e0e0) at src/devices/ovs/nm-device-ovs-interface.c:95
#8 _nm_device_check_connection_available (self=0x56356647b1b0 [NMDeviceOvsInterface], connection=0x56356627e0e0, flags=NM_DEVICE_CHECK_CON_AVAILABLE_NONE, specific_object=0x0) at src/devices/nm-device.c:12102
#9 nm_device_check_connection_available (self=self@entry=0x56356647b1b0 [NMDeviceOvsInterface], connection=0x56356627e0e0, flags=flags@entry=NM_DEVICE_CHECK_CON_AVAILABLE_NONE, specific_object=specific_object@entry=0x0) at src/devices/nm-device.c:12131
#10 nm_device_recheck_available_connections (self=self@entry=0x56356647b1b0 [NMDeviceOvsInterface]) at src/devices/nm-device.c:12238
#11 _set_state_full (self=self@entry=0x56356647b1b0 [NMDeviceOvsInterface], state=state@entry=NM_DEVICE_STATE_FAILED, reason=reason@entry=NM_DEVICE_STATE_REASON_OVSDB_FAILED, quitting=quitting@entry=0) at src/devices/nm-device.c:13065
#12 nm_device_state_changed (self=self@entry=0x56356647b1b0 [NMDeviceOvsInterface], state=state@entry=NM_DEVICE_STATE_FAILED, reason=reason@entry=NM_DEVICE_STATE_REASON_OVSDB_FAILED) at src/devices/nm-device.c:13328
#13 del_iface_cb (error=<optimized out>, user_data=0x56356647b1b0) at src/devices/ovs/nm-device-ovs-port.c:160
#14 _transact_cb (self=self@entry=0x5635662b9ba0 [NMOvsdb], result=result@entry=0x0, error=0x563566259a10, user_data=user_data@entry=0x5635662ff320) at src/devices/ovs/nm-ovsdb.c:1449
#15 ovsdb_disconnect (self=self@entry=0x5635662b9ba0 [NMOvsdb]) at src/devices/ovs/nm-ovsdb.c:1331
#16 dispose (object=0x5635662b9ba0 [NMOvsdb]) at src/devices/ovs/nm-ovsdb.c:1558
#17 g_object_unref (_object=0x5635662b9ba0) at gobject.c:3293
#18 _nm_singleton_instance_destroy () at src/nm-core-utils.c:138
#19 _dl_fini () at dl-fini.c:253
#20 __run_exit_handlers (status=status@entry=0, listp=0x7fbb3e1ad6c8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:77
#21 __GI_exit (status=status@entry=0) at exit.c:99
#22 main (argc=1, argv=0x7fffb4b2cc38) at src/main.c:468
Add a new error code to indicate to callbacks that we are quitting and
no further action must be taken. This is preferable to having
additional references because it allows us to free the resources owned
by callbacks immediately, while references can easily create loops.
https://bugzilla.redhat.com/show_bug.cgi?id=1543871
(cherry picked from commit cf79615169)
Always reschedule a lease renewal attempt: just clear the scheduled
renewal if the connection is really deactivated.
(cherry picked from commit 1a20ff86d5)
Example: when dhcpv4 lease renewal fails, if ipv4.may-fail was "yes",
check also if we have a successful ipv6 conf: if not fail.
Previously we just ignored the other ip family status.
(cherry picked from commit da0fee4d9f)
The secrets are transient -- when they are loaded into the connections and
subsequently cleared the connection itself doesn't change. The Update
signal is to be emmited only on explicit Update()/Update2() or
ClearSecrets() which is already the case.
Apart from Update being wrong, it has the ill effect of causing libnm to
drop secrets from the cached connection.
(cherry picked from commit 66ae0cc306)
After writing the connection to disk and rereading it, in addition to
restoring agent-owned secrets in the cache we must also restore
agent-owned secrets from the original connections since they are lost
during the write.
Reported-by: Märt Bakhoff <anon@sigil.red>
https://bugzilla.gnome.org/show_bug.cgi?id=793324
(cherry picked from commit f9c50bf3d3)
It looks bad and makes everyone super-sad:
$ nmcli --ask c modify 'Oracle HQ' 802-11-wireless-security.psk solaris666
System policy prevents modification of network settings for all users
(action_id: org.freedesktop.NetworkManager.settings.modify.system)
Password (lkundrak): *********
$
(cherry picked from commit de9b74452c)
With --ask it might call back to nmcli's agent, causing a deadlock
while the client is waiting for the response. Let's give the client
a chance to service the agent requests while waiting:
$ nmcli --ask --show-secrets c show 'Oracle HQ'
<hang>
This is probably still rather suboptimal and inefficient, since we
still serialize the calls and block on response. However, if we submit
multiple calls to GetSecrets, the daemon would start authorizing the
first one and fail the other ones immediately before the authorization
succeeds.
This could perhaps be addressed in the daemon, but let's settle for a
fix that's compatible with the current daemon for now.
(cherry picked from commit 9bf0b32cd1)
The bridge test (and no other either) no longer sets sysfs properties,
so this whole madness is no longer needed. That is good, because Linux
got somewhat stricter (at least in 4.15) about mounting sysfs and the
whole thing wouldn't work with containers where /sys is red-only from
the start.
(cherry picked from commit 6788ced98d)
It's nicer but also doesn't annoy gcc 8: "error: ‘strncpy’ specified bound
depends on the length of the source argument [-Werror=stringop-overflow=]"
(cherry picked from commit 85c0dc4a92)
This is basically the case in the COPR build system where this
(mount -o bind,ro /proc/sys /proc/sys) is the case for reasons unknown.
(cherry picked from commit 984e9d5655)
Substrings matching the heading of valid values were allowed if not
ambiguous (e.g.: "et" for "eth"). Moreover, upper case variants were
accepted too.
Do a plain string comparison check against the valid values.
Improve also the error message: give a list of valid tx-hashes.
(cherry picked from commit fd5b3f802e)
Will be used by CI trigger to name packages that are build during testing
of a github pull request with the corresponding pull request ID.
"build_clean.sh" now supports a command line option -s|--snapshot. But the
same paramter can also be set via $NM_BUILD_SNAPSHOT environment
variable. Using the environment variable is useful to support older versions
and new versions of "build_clean.sh", so that the script can just ignore the
snapshot setting if it doesn't understand it yet.
(cherry picked from commit 86a18b2df2)
Previously we always updated resolv.conf on quit. When we are using
systemd-resolved the update is not necessary because the resolver on
127.0.0.53 would still be reachable after NM quits. Also, when NM
manages resolv.conf directly there is no need to update the file
again. Let's rewrite resolv.conf only when using dnsmasq.
https://bugzilla.redhat.com/show_bug.cgi?id=1541031
(cherry picked from commit 37eed6984b)
The code was passing the gpointer alias of the GValue, rather than the
GValue* itself. This doesn’t matter normally, but broke an experimental
patch in GLib to remove a cast from G_VALUE_TYPE.
We’ve reverted the patch in GLib (see
https://bugzilla.gnome.org/show_bug.cgi?id=793186), but this should be
fixed in NetworkManager anyway.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=793302
(cherry picked from commit daadb8fbe9)
The RPM build should be not use silent output -- it better be possible
to check whether the correct compiler flags were present at the build
time.
(cherry picked from commit c4c8ffd113)
If IPV6CP terminates before IPCP, pppd enters the RUNNING phase and we
start IP configuration without having an IP interface set, which
triggers assertions. Instead, reimplement stage3_ip6_config_start to
be a no-op. Note that IPv6 configuration on PPP devices has never been
supported by NM.
This is a simpler version of upstream commit dd98ada33f ("ppp:
introduce SetIfindex pppd plugin D-Bus method") that doesn't require
changing the internal plugin API.
https://bugzilla.redhat.com/show_bug.cgi?id=1515829
Setting the state of NMActiveConnection results in invoking callbacks
in NMManager. Hence, it might be far-reaching. Clear
priv->queued_act_request before invoking the callbacks.
(cherry picked from commit ecf3677e57)
Don't just directly switch to DISCONNECTED state. If we are ACTIVATING
or ACTIVATED, first transition to DISCONNECTING state.
(cherry picked from commit 6d623825f6)
There is a small change in behavior:
Previously, the DEACTIVATING/DEACTIVATED states were set if and only if
the previous state was less or equal then ACTIVATED. For example,
if the state was already DEACTIVATING, it would have done nothing.
Now, nm_active_connection_set_state_fail() transitions the states
depending on the previous state. E.g. it would only set DEACTIVATING
state, if the previous state was ACTIVATING/ACTIVATED. On the other hand,
it would always progress the state to DEACTIVATED.
The new behavior makes more sense to me, although I doubt that there is
a visible difference.
(cherry picked from commit c5a97ad265)
unmanaged_to_disconnected() is supposed to mark the device as managed.
However, it may easily be unable to do so, for example if the device
is unmanaged by NM_UNMANAGED_USER_SETTINGS.
Shortly before actually enqueuing the activation request, check and
error out. Otherwise, we might hit an assertion later in
_device_activate().
(cherry picked from commit c6d0fbe7b0)
Note how recheck_assume_connection() called:
nm_exported_object_export (NM_EXPORTED_OBJECT (active));
active_connection_add (self, active);
nm_device_queue_activation (device, NM_ACT_REQUEST (active));
That differs from the order during _internal_activate_generic(), where
we would end up with:
nm_exported_object_export (NM_EXPORTED_OBJECT (active));
nm_device_queue_activation (device, NM_ACT_REQUEST (active));
active_connection_add (self, active);
It makes more sense to me to *first* add the connection, and only then
starting the activation with nm_device_queue_activation().
Also, let active_connection_add() always export the new active
connection object, if it is not already exported. All callers of
active_connection_add() ensured that the new object is already
exported.
(cherry picked from commit 6b08d2dda2)
