There can be multiple default routes for an interface with different
metrics. Grab the gateway of the default route with the lowest
metric as the overall gateway of the IP config. Otherwise the rest
could get left in the config and applied at random times.
If the interface who's IP configuration is being captured has the default
route, then read DNS servers from resolv.conf into the NMIP[4|6]Config.
This allows NetworkManager to repopulate resolv.conf if anything changes.
For example, if the system does not define a persistent hostname, then
when a device which has generated a connection activates, a hostname
lookup will be performed. The results of that lookup may change resolv.conf,
and thus NetworkManager must rewrite resolv.conf. Without capturing
DNS information at startup when generating connections, an empty
resolv.conf would be written.
When generating connections at startup for active interfaces, the
generation code may not always be able to read DNS information for
the connection. Thus, the device's IP4Config won't have any
nameservers and the device won't be considered for reverse-address
lookup. However, since any device that gets this far is already
the "best" device and has the default route, and thus should be the
one used for reverse-address lookup.
Second, reorganize the code better handle dual-stack in the
future by checking the IP configs directly, instead of the
devices. Since 'best4' and 'best6' may be different devices,
we want to operate on the IP configs, not devices, to handle
situations where the best IP4Config may not be suitable for
reverse lookup, but the best IP6Config is.
https://bugzilla.redhat.com/show_bug.cgi?id=1031763
When doing nm_auth_chain_unref(), the code iterated over the ->calls and
cancelled them. However, some of these calls might not have passed on to
polkit_authority_check_authorization(), but instead being scheduled with
g_idle_add(). These calls have to be canceled too because the NMAuthChain
will already be destroyed when auth_call_complete() calls.
Now, we g_source_remove() these calls and free them immediatly. Before
these calls leaked and led to use after free crash.
Also fix a memory leak by always get the results with
polkit_authority_check_authorization_finish(), even when being
cancelled.
This is the backtrace of the crash:
#0 0x00007f166efda359 in g_slist_remove () from /lib64/libglib-2.0.so.0
#1 0x00007f167311bcc1 in auth_call_complete ()
#2 0x00007f166efbde06 in g_main_context_dispatch ()
from /lib64/libglib-2.0.so.0
#3 0x00007f166efbe158 in g_main_context_iterate.isra.22 ()
from /lib64/libglib-2.0.so.0
#4 0x00007f166efbe55a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#5 0x00007f16730d3c0d in main ()
Co-Authored-By: Dan Williams <dcbw@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
The router has no idea what the local configuration or user preferences are,
so sending routes with a prefix length of 0 is at best misinformed and at
worst breaks things. The kernel also ignores plen=0 routes in its in-kernel
RA processing code in net/ipv6/ndisc.c.
https://bugzilla.redhat.com/show_bug.cgi?id=1029213
Else loopback is managed, and could be easily disconnected, which causes various
issues with applications. So do not manage it for now, to be on the safer side.
https://bugzilla.redhat.com/show_bug.cgi?id=1032594
When activating a team slave and 'teamd' binary is not installed, the
priv->state of master device will be NM_DEVICE_STATE_FAILED, which is greater
than NM_DEVICE_STATE_ACTIVATED.
<info> Activation (nm-team) Stage 1 of 5 (Device Prepare) started...
<warn> Activation (nm-team) to start teamd: not found
<info> (nm-team): device state change: prepare -> failed (reason 'none') [40 120 0]
...
<debug> master_state_cb(): (0x81d6968): master ActiveConnection [0x91d69d0] 'team0' failed
<info> (eth1): device state change: config -> failed (reason 'dependency-failed') [50 120 50]
...
<debug> slave_state_changed(): (nm-team): slave eth1 state change 50 (config) -> 120 (failed)
--- ASSERTION ---
Set accept_ra and use_tempaddr to "0" when managing a device (and
restore them to their original values after unmanaging it) to ensure
that calling nm_device_bring_up() on a managed device won't ever cause
kernel IPv6 autoconf to happen. Remove some other redundant accept_ra
setting.
Fix up the deconfigure case of dispose() to clear the device's IP6
config as well as its IP4 config.
https://bugzilla.gnome.org/show_bug.cgi?id=700414
update_accept_ra_path() and update_ip6_privacy_save() were freeing
their path variables if they failed to read the existing values, but
if this ever actually happened it would cause problems later since
other code assumed that the variables were always set. Use
"priv->ip6_accept_ra_save = -1", etc, instead to indicate that the
value couldn't be read (and so shouldn't be restored later).
Merge the accept_ra and use_tempaddr code save/restore code together,
since they're always called together.
Fix the accept_ra-restoring code to correctly handle an original value
of "2".
Call update_ip6_properties_paths() from nm_device_set_ip_iface()
rather than act_stage3_ip6_config_start(), since set_ip_iface() is
when the paths actually change. Also, split the default-value-saving
code out into a separate function, since we only care about doing that
at construct time; if the IP6 property paths change later (because
iface != ip_iface), then we don't need to save and restore the values
on the ip_iface, since the interface will go away when we're done with
it.
https://bugzilla.gnome.org/show_bug.cgi?id=700414
Rename ip6_privacy_tempaddr_path and ip6_privacy_tempaddr_save to
ip6_use_tempaddr_*, to match the sysctls, for consistency with the
accept_ra variables.
We used to call nm_device_deactivate() when moving a device from
UNMANAGED to UNAVAILABLE (unless we were assuming the existing
connection), but this got lost when default-unmanaged was added. Fix
it to do this again, so the device will be in a known-clean state when
it is activated.
Previously, the default wired connection was removed on quit when the
device was cleaned up. This is inconsistent with other connections.
Leave the default wired connection up when quitting to fix this
inconsistency.
This allows default wired connections to be assumed when NM starts.
It is useful to bind the loopack connection to the loopback interface,
and it also allows activating it.
$ nmcli con up lo
Else "Error: no device found for connection 'lo'" is returned, because
connection_compatible() in libnm-glib/nm-device-generic.c wants the
connection to have an interface-name set.
The change to allow an NMConnection to only be active on a single
device accidentally broke the case of re-activating a connection on
the same device. Fix that.
Changing the default wired connection has always deleted the connection
(thus disconnecting the interface) and re-added it as a settings plugin
connection. That was always sub-optimal, but until the 'unsaved' connection
stuff landed this summer, we couldn't do anything about that. Clean
that all up, adding the connection as an unsaved connection right from
the start, which allows changes to the connection without having to
delete and recreate it, thus preventing disconnection of any interface
that is using the connection.
A new signal is added to NMSettingsConnection that is only emitted when
the connection is changed from D-Bus (thus indicating an explicit user-
requested change) since the connection may be modified internally by
NetworkManager. NM-triggered changes should not result in the connection
no longer being a default-wired connection.
https://bugzilla.gnome.org/show_bug.cgi?id=712188https://bugzilla.redhat.com/show_bug.cgi?id=1029464
These are (most likely) only warnings and not severe bugs.
Some of these changes are mostly made to get a clean run of
Coverity without any warnings.
Error found by running Coverity scan
https://bugzilla.redhat.com/show_bug.cgi?id=1025894
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
wifi_utils_get_qual returns -1 on error. Keeping it in an unsigned
variable is a bug.
Error found by running Coverity
https://bugzilla.redhat.com/show_bug.cgi?id=1025894
Signed-off-by: Thomas Haller <thaller@redhat.com>
If the connection has never been saved to disk, it won't have a path yet,
but that doesn't mean we should crash. Next, when reloading connections,
only try to do connection matching on connections that have paths, otherwise
all in-memory-only connections would be removed at the end of
read_connections().
Doing so may cause NetworkManager to run into an very intensive loop in
svUnescape() in shvar.c.
This is 'top' output for very long (invalid team config) - 9309865 bytes long:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26855 root 20 0 305m 35m 6092 R 99.8 0.9 8:08.11 NetworkManager
and still not finished.
If an assumed bridge/bond/team/whatever happened to be in the process
of activating (perhaps it had no recognized slaves and was waiting for
them to continue with IP configuration) when NM quits, don't deactivate
the device and blow away the assumed configuration.
Don't set NMManager:state to CONNECTING when assuming a connection,
since it's not actually "connecting".
If there are active connections, but none has the default route, then
the global state should be CONNECTED_LOCAL, not CONNECTED_GLOBAL.
Also tweak the semantics of CONNECTING/DISCONNECTING slightly; we only
set state to CONNECTING when connecting a new connection if we are not
already CONNECTED_GLOBAL, and we only set it to DISCONNECTING if we
will be DISCONNECTED afterward.
Assumed connections shouldn't require touching the device, and the
device should was already set IFF_UP during stage2 (which is
skipped for assumed connections). Instead, what the code was really
trying to do, was to ensure tha the IP interface the device was
going to use was up.
The only cases where the IP interface might *not* be up after stage2
is where the IP interface is different than the device's interface,
like for Bluetooth, ADSL, WWAN, and PPPoE. Move the call to
nm_platform_link_set_up() into nm_device_set_ip_iface() which all
those device types will call.
Thus, only the device types that really need to up their IP interface
will do so, but other devices (including when activating assumed
connections) that don't need to do this, won't do it.
If the device has no IP configuration, is not a slave, and is not
a master, there's no point in generating a connection for it and
assuming that connection.
Fixes a problem where tun devices created by vpnc would be activated
with an empty assumed connection before NetworkManager could assign
the VPN IP config to it, and since IPv6 link-local timed out, the tun
device would be deactivated and VPN would be useless.
Follow the IP configuration the device currently has. For IPv6, this means
not using LINK_LOCAL if the interface doesn't have a LINK_LOCAL address.
Otherwise, NM assumes too much and may begin to activate an interface that
has no IP configuration, then time out and deactivate that device.
Assumed slave connections need to be added to their master devices,
which didn't used to happen because the devices activating assumed
connections jumped directly to stage3, bypassing all the master/slave
handling stuff.
Instead, make all assumed connections go through all activation stages,
but make sure that things which touch the device don't get done for
assumed connections. This requires moving the master/slave code out
of the override-able class methods because we need to call the
master/slave code for assumed connections, but we don't want to call
the override-able class activation methods.
If an assumed connection should have a master (bridge port, bond slave,
etc) it needs to notify its master that it's a slave. Since slaves
are ordered after their masters at start, the master should already
have a generated connection which we can use as the master.
Various code during the activation paths will want to know whether
the connection is assumed or not, so that it doesn't do stuff that
touches the device.
If the device has a valid generated connection, it's already applied
and the device is already "activated" outside NM, so let activation
happen inside NM regardless of whether the device is available or not
according to NM.
Slaves should get sorted after their masters so that when generating
connections, the NMManager knows about the masters already.
The convoluted logic here is to ensure that:
1) the kernel doesn't pass bad information that causes NM to crash
or infinite loop
2) that with complicated parent/child relationships (like a VLAN interface
with a parent that is also a slave), children always get sorted after
*all* of their ancestors. The previous code was only sorting children
after their immediate parent/master's ifindex, but not actually after
the parent in the returned list.
