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.
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.
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).
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.
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
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
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
IEEE_80211_IE_VHT_CAP has zero hits searching the internet.
WLAN_EID_VHT_CAPABILITY is how the same define is called by
kernel's "include/linux/ieee80211.h".
Use the same name as kernel.
Also, collect the maximum of @max_rate.
Currently, 'nmcli dev wifi list' does not show the user any rates above
54Mbps. Now, we can check the IEs passed to NM from the wpa_supplicant,
pull the mcs rate and channel width information, and determine a maximum
possible data rate for 11n and 11ac APs.
https://bugzilla.gnome.org/show_bug.cgi?id=779771
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;
^
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;
^
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;
^
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
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
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
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.
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
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.
libnm contains the public function nm_utils_enum_from_str() et al.
The function is not flexible enough for nmcli's usecase. So, I would
need another public function like nm_utils_enum_from_str_full() that
has an extended API.
That was already required previously for ifcfg-rh writer, but in that
case I could just add it as internal API as libnm-core is linked statically
with NetworkManager.
I don't want to commit to a public API for an utility function. So move
the code instead to the shared directory, so that nmcli may link
statically against it and use the internal API.
This part contains static functions and variables to describe
settings. It is distinct from the mechanism to use them, or
access them.
Split it out.
It still uses clients/cli/common.h and clients/cli/utils.h
which shall be fixed next.
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
