Set the device state as removed when the link disappears, so that in
the call to unrealize() when the device is unmanaged we also perform a
cleanup of it and especially, we terminate any DHCP client instances
running on the device.
If we keep DHCP clients running, we can hit assertions later when we
start another instance on the same interface, because we kill the old
dhclient from the pidfile, and the g_child_watch_add() done by the
first client instance is not able to waitpid() it, complaining with:
GChildWatchSource: Exit status of a child process was requested but
ECHILD was received by waitpid(). Most likely the process is
ignoring SIGCHLD, or some other thread is invoking waitpid() with a
nonpositive first argument; either behavior can break applications
that use g_child_watch_add()/g_spawn_sync() either directly or
indirectly.
https://bugzilla.redhat.com/show_bug.cgi?id=1436602
(cherry picked from commit df537d2eac)
src/NetworkManagerUtils.c:347:18: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
NMIPAddr a1 = { 0 }, a2 = { 0 };
^
{}
Should we initialize unions this way? I think it's all right -- the initializer
works well and { { { 0 } } } is probably not what we'd like to see.
(cherry picked from commit 43012156a3)
The input list of routes is allowed to contain non-normalized routes,
that is, routes which host part is non-zero. Such routes are rejected
by kernel, but NM should transparently allow them (by normalizing
the host part).
The ID comparison function route_id_cmp() already properly ignored
the (possibly non-zero) host part. However, in the internal list we
also should make sure not to track such routes. We achive that by
normalizing the host part to zero.
Note that below we check whether the tracked route is idential to
the route configured at platform. If we don't normalize the host part,
the comparison will always indicate that the route is not yet
configured, and thus we will re-sync the route every time.
(cherry picked from commit 5c54b7a31e)
Kernel requires that routes have a host part of zero. For NetworkManager
configuration we allow non-zero host parts (but ignore them). Fix
route_compare() to ignore the host part.
This has only effect during assuming connections. That means, on
restart NM would fail to match a connection with static routes
if it has a non-zero host part. So, the impact is rather small.
(cherry picked from commit 034b7fb51c)
Routes with a non-zero host part are not allowed by kernel and
don't really exist. We didn't reject such routes in users configuration,
so various part of NM allow such routes. NM should silently strip
the host part.
Extend the cache's route ID to clear the host part too.
Note that NM's handling of routes is fundamentally flawed, as
for kernels routes don't have an "id" (or rather: all properties
of a route are part of it's ID, not only the family,ifindex,
network/plen and metric tuple (see related bug rh#1337855).
(cherry picked from commit 57b0dce083)
Platform's add/remove operations accept a "network" argument.
Kernel requires that the host part (based on plen) is all zero.
For NetworkManager we are more resilient to user configuration.
Cleanup the input argument already before calling _nl_msg_new_route().
Note that we use the same "network" argument to construct a obj_id
instance and to find the route in the cache (do_add_addrroute()).
Without cleaning the host part, the added object cannot be found
and the add-route command seemingly fails.
(cherry picked from commit 11d8c41898)
Got an assertion due to priv-proxy unset.
NMDevice:
- _platform_link_cb_idle()
- nm_device_unrealize() [NMDeviceTun]
- nm_device_state_changed()
- _set_state_full()
NMVpnConnection:
- _set_vpn_state()
- call_plugin_disconnect()
It seam to me, that can only happen if the NMVpnConnection never
completed on_proxy_acquired() and is still in preparing state when
being disconnected.
Avoid that be checking whether we have a proxy.
https://bugzilla.redhat.com/show_bug.cgi?id=1442064
(cherry picked from commit bc1d1c9df4)
If the D-Bus call to DeactivateConnection() fails, don't wait for the
connection to change state because this is not going to
happen. Instead, notify the user of the error and, if necessary, wait
for remaining connections to be deactivated.
https://bugzilla.redhat.com/show_bug.cgi?id=1422786
(cherry picked from commit 67d144dd1e)
It's perfectly valid to call the function with out_connection == NULL
when connection_hash == NULL too, as cancel_get_secrets() does.
Fixes: fbb1662269
(cherry picked from commit c4a0002f05)
When a VPN connection can't be activated we have to unexport and
dispose it. Commit f2182fbf9b ("core: don't emit double
PropertiesChanged signal for new active connections") removed the call
to nm_exported_object_unexport() in case of failure because the active
connection already gets unreferenced on failure.
However, an exported object can't be disposed until it's explicitly
unexported because GDBus code keeps a reference to it. The result was
that the active connection was kept alive and exported, but without
explicit references to it. As soon as the connection was unexported,
it was also automatically disposed, causing issues like:
(src/nm-exported-object.c:1025):dispose: code should not be reached
#0 _g_log_abort () at /lib64/libglib-2.0.so.0
#1 g_logv () at /lib64/libglib-2.0.so.0
#2 g_log () at /lib64/libglib-2.0.so.0
#3 g_warn_message () at /lib64/libglib-2.0.so.0
#4 dispose (object=0xaaf110) at src/nm-exported-object.c:1025
#5 dispose (object=0xaaf110) at src/nm-active-connection.c:1246
#6 dispose (object=0xaaf110) at src/vpn/nm-vpn-connection.c:2642
#7 g_object_unref () at /lib64/libgobject-2.0.so.0
#8 registration_data_free () at /lib64/libgio-2.0.so.0
#9 g_hash_table_remove_internal () at /lib64/libglib-2.0.so.0
#10 g_dbus_object_manager_server_unexport_unlocked () at /lib64/libgio-2.0.so.0
#11 g_dbus_object_manager_server_unexport () at /lib64/libgio-2.0.so.0
#12 nm_bus_manager_unregister_object (self=0x9069e0, object=object@entry=0xaaf110) at src/nm-bus-manager.c:858
#13 nm_exported_object_unexport (self=0xaaf110) at src/nm-exported-object.c:714
#14 _settings_connection_removed (connection=<optimized out>, user_data=0xaaf110) at src/nm-active-connection.c:184
#15 g_closure_invoke () at /lib64/libgobject-2.0.so.0
#16 signal_emit_unlocked_R () at /lib64/libgobject-2.0.so.0
#17 g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
#18 g_signal_emit_by_name () at /lib64/libgobject-2.0.so.0
#19 nm_settings_connection_signal_remove (self=self@entry=0x9e4a80, allow_reuse=allow_reuse@entry=0) at src/settings/nm-settings-connection.c:2085
#20 do_delete (self=0x9e4a80, callback=0x58106a <con_delete_cb>, user_data=0xa84fa0) at src/settings/nm-settings-connection.c:768
#21 do_delete (connection=0x9e4a80, callback=0x58106a <con_delete_cb>, user_data=0xa84fa0) at src/settings/plugins/keyfile/nms-keyfile-connection.c:127
#22 nm_settings_connection_delete (self=self@entry=0x9e4a80, callback=callback@entry=0x58106a <con_delete_cb>, user_data=0xa84fa0) at src/settings/nm-settings-connection.c:694
#23 delete_auth_cb (self=self@entry=0x9e4a80, context=context@entry=0x7fffd80131e0, subject=0x91fb40, error=<optimized out>, data=data@entry=0x0) at src/settings/nm-settings-connection.c:1879
#24 pk_auth_cb (chain=0x7fffd00024a0, chain_error=<optimized out>, context=0x7fffd80131e0, user_data=<optimized out>) at src/settings/nm-settings-connection.c:1351
#25 auth_chain_finish (user_data=0x7fffd00024a0) at src/nm-auth-utils.c:92
#26 g_idle_dispatch () at /lib64/libglib-2.0.so.0
Restore the unexport upon failure to fix this.
Fixes: f2182fbf9bhttps://bugzilla.redhat.com/show_bug.cgi?id=1440077
(cherry picked from commit 69fd96118e)
The address change involves setting the link down which causes the supplicant
interface to change state and in turn another scan attempt. This could lead to
a loop in case of broken drivers that are not able to change the MAC address
iff the MAC address is attempted at each scan request.
https://bugzilla.redhat.com/show_bug.cgi?id=1382741
(cherry picked from commit 0234172923)
Call get_device_list() after next_arg(); call it only after checking
that there are other arguments after "monitor".
Fixes: 6a3d77fbe6
(cherry picked from commit 2c4e991aba)
If a configuration does not have a path it is because we are still
sending it to pacrunner or because we failed to do so. In both cases,
we have to remove the configuration from the list.
Fixes: 3ad89223d0
(cherry picked from commit fad2cf0721)
Don't try to remove the configuration if we haven't added it in the
first place, for example when the connection gets deactivated before
it completes or for slave connections without IP configuration.
Fixes: 3ad89223d0
(cherry picked from commit 3cada7722d)
If a VPN provides a proxy, we want to restrict the usage of that proxy
to URLs in the VPN domain. For all other connections, the proxy should
be used for all domains.
(cherry picked from commit b139552255)
Fix some issues in nm-pacrunner-manager.c:
- when adding a configuration through nm_pacrunner_manager_send(), we
kept an association between the interface name and the pacrunner
configuration object path, so that the configuration for that
interface could be removed later. Unfortunately not all
configurations have an interface associated, so we need a more
generic way to identify configurations. Introduce a new @tag
argument that serves as key to match configurations
- the interface name of the last pushed configuration was stored in
the manager private config and reused later; this could cause
issues when there are multiple outstanding D-Bus calls. The
interface is not needed anymore after the previous point.
- remove() didn't actually remove the configuration from the list
(cherry picked from commit 3ad89223d0)
src/devices/nm-device-bond.c: In function 'check_changed_options':
src/devices/nm-device-bond.c:529:4: error: 'name' may be used uninitialized in this function [-Werror=maybe-uninitialized]
g_set_error (error,
^
src/devices/nm-device-bond.c:505:14: note: 'name' was declared here
const char *name, *value_a, *value_b;
^
src/devices/nm-device-bond.c:528:8: error: 'value_a' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!nm_streq0 (value_a, value_b)) {
^
src/devices/nm-device-bond.c:505:21: note: 'value_a' was declared here
const char *name, *value_a, *value_b;
^
(cherry picked from commit f66de1dd0f)
src/nm-auth-utils.c:343:6: error: 'is_authorized' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (is_authorized) {
^
src/nm-auth-utils.c:320:11: note: 'is_authorized' was declared here
gboolean is_authorized, is_challenge;
^
src/nm-auth-utils.c:346:13: error: 'is_challenge' may be used uninitialized in this function [-Werror=maybe-uninitialized]
} else if (is_challenge) {
^
src/nm-auth-utils.c:320:26: note: 'is_challenge' was declared here
gboolean is_authorized, is_challenge;
^
(cherry picked from commit 24ab2a4945)
src/nm-default-route-manager.c: In function '_ipx_update_default_route':
src/nm-default-route-manager.c:769:23: error: 'is_assumed' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!default_route && !is_assumed) {
^
src/nm-default-route-manager.c:763:13: note: 'is_assumed' was declared here
gboolean is_assumed;
^
(cherry picked from commit 857f26dd19)
For example, when starting without Wi-Fi plugin, a generic device
is created. On stop, we should not store the unmanaged state
on the state file, otherwise after restart the device is unmanaged.
Only store explicit user decisions.
https://bugzilla.redhat.com/show_bug.cgi?id=1440171
(cherry picked from commit 142ebb1037)
The function is supposed to set *unamanged to NM_UNMANAGED's and indicate
whether NM_UNMANAGED was present in the return value.
Fixes: e32839838e
(cherry picked from commit b7b0227935)
Options dependant on specific commands (e.g., nmcli connection show
--active) are now allowed to be processed by the next_arg() function.
This would allow autocompletion to expand options belonging to specific
command first, and then global ones.
Note that global options ("--ask" and "--show-secrets") will be auto-completed
everywhere but only if at least a '-' is passed. Command specific ones
(--temporary, --active, --order) will be auto-completed only after the command
they belongs to but without requiring the user to pass a heading '-'.
Example:
'nmcli connection show -a'
will expand '-a' into '--active', but
'nmcli connection add -a`
will expand '-a' into '--ask' (as it is a global option)
This commit fixes also autocompletion for:
nmcli connection modify --temporary
(cherry picked from commit 6a3d77fbe6)
This happens when the connection is in "activating" state and
the connection is a master one waiting for slaves: "check_activated()"
is called by the active_connection_state_cb() and device_state_cb() callbacks.
If the device has already moved to a state >= NM_DEVICE_STATE_IP_CONFIG, the
call to active_connection_state_cb() will end calling
activate_connection_info_finish(), freeing the "info" object. The subsequent
call to device_state_cb() will result in accessing the freed "info".
Just call check_activated() once after registering the
active_connection_state() and device_state_cb() callbacks.
(cherry picked from commit 3d4d1bedda)
We now update the default route metric based on the result of the
connectivity check. When we update the metric and there is no other
changes to the IP configuration, NMPolicy is not notified about it and
can't update the best device until an actual change in IP config
happens. This results in a wrong best device set in NMPolicy.
NMDevice has NM_DEVICE_IP[4,6]_CONFIG_CHANGED signals that are used
exclusively by NMPolicy to detect when there is a change in
configuration that requires an update of global DNS and routing
information. Emit those signals also when the default route changes.
(cherry picked from commit 3fe144f934)
Commit 029a0a21ea ("device: split out cloned MAC decision from
nm_device_hw_addr_set_cloned()") accidentally removed the assignment
of the new device @hw_addr_type, which then was left to
HW_ADDR_TYPE_UNSET. As a consequence, we never restored the initial
MAC address when the connection was deactivated. Fix this.
Fixes: 029a0a21ea
(cherry picked from commit 166988264f)
Fixes the parsing for correct and incorrect commands.
e.g.:
nmcli connection down id <conn>
nmcli -t
...
Fixes: 16902a2be6
(cherry picked from commit ef0d0d08eb)
