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>
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.
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 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.
teamd_cleanup() might get called multiple times, and since the rest
of the function is safe against multi-calls, make priv->tdc safe
against being called again too.
rh #1025371 reports a crash in handle_ip_config_timeout() because
nm_device_wifi_get_activation_ap() did not return any access point.
The handling of the AP in nm-device-wifi.c should be reworked and soon
will be fixed. For now, play it safe, and try to cope with any cases
where nm_device_wifi_get_activation_ap() might return NULL.
Later, this patch should be reverted and handling of the AP properly
cleaned up.
https://bugzilla.redhat.com/show_bug.cgi?id=1025371
Signed-off-by: Thomas Haller <thaller@redhat.com>
With the methods 'auto' and 'link-local' we check now, that the device
has a usable IPv6 LL address configured (after DAD, no longer tentative).
We wait for up to 5 seconds, for a suitable LL address to appear.
Currently, if the address does not get ready, we don't create one and
IPv6 configuration fails.
This is relevant for the methods 'link-local' and 'auto'. In the latter
case, because we cannot send router solitations without link local
address.
https://bugzilla.gnome.org/show_bug.cgi?id=707155
Signed-off-by: Thomas Haller <thaller@redhat.com>
In act_stage3_ip6_config_start, for IPv6 mode link-local, we check
if there is already an IPv6 address configured. If yes, we are
already done.
For now, as current workaround, if the LL does not exist, we
NM_ACT_STAGE_RETURN_STOP.
Later, we will POSTPONE and wait a timeout until we see a LL address
that is no longer TENTATIVE. The same should be done for method auto,
so that the device is usable to send router solitations (bgo#707155).
https://bugzilla.gnome.org/show_bug.cgi?id=707155https://bugzilla.gnome.org/show_bug.cgi?id=706618
Signed-off-by: Thomas Haller <thaller@redhat.com>
Master devices depend on their slaves/ports for carrier status, so the
carrier can't factor into whether a connection is available on that
device or not. If it did, then no connections could be activated
because the device doesn't have a carrier until slaves are attached.
Previously, ignore-carrier devices were always in the unavailable state
until they were activated. This required some complicated code to keep
track of whether the device was available or not based on what connections
existed, whether those connections were static-IP, and whether the device
was ignore-carrier. Various bits of the code used nm_device_can_activate()
for two different purposes: (1) to determine if the device was available
on an L2 basis, which nm_device_can_activate() wasn't well-suited to, and
(2) whether a specific connection could be activated at a given time
based on ignore-carrier and whether the connection was static IP or not.
Remove that complexity and confusion by making ignore-carrier devices
always move to DISCONNECTED state, and simply refuse to activate
connections that require connectivity, but allow connections that don't
require connectivity. Also, when the device has no carrier, don't
add connections that require connectivity to the AvailableConnections
device property.
Use the new kernel physical_port_id interface property to recognize
when two devices are just virtual devices sharing the same physical
port, and refuse to bond/team multiple slaves on the same port.
If nm_device_enslave_slave() failed, the slave would log that it was
waiting for the master to activate (even if the master was already
active). Fix it to log an error and fail its activation instead.
When ActiveConnections take over authentication, it may mean that the
master active connection is still handling authentication when the
slave starts to activate. Thus the master device may still be in
DISCONNECTED state and not ready to enslave the slave.
We need to track the master active connection, since it may require authentication
or other operations to complete before the device actually starts activating.
Support new bonding options and set them carefully. The options cannot
be set arbitrarily because they interfere with each other.
This commit is forward-ported from rhel-6.5, see patch
rh901662-bond-more-options.patch, originally written by Dan Williams.
https://bugzilla.redhat.com/show_bug.cgi?id=901662https://bugzilla.redhat.com/show_bug.cgi?id=905532
Co-Authored-By: Dan Williams <dcbw@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
When an interface is manually disconnected NM remembers that, and prevents
automatic activation of the device.
However, software devices are removed when they are disconnected, and thus
the state of the device is lost. We need to track autoconnect outside the
device - hash table of interface names not allowed to activate automatically.
Without that the device would be auto-activated again and again, even if
explicitly disconnected.
Test case:
$ nmcli con add type bond ifname bb con-name bb-con
$ nmcli con add type bond-slave ifname em1 con-name b1-con master bb
$ nmcli dev disconnect bb
https://bugzilla.redhat.com/show_bug.cgi?id=1005913
When freeing one of the collections such as GArray, GPtrArray, GSList,
etc. it is common that the items inside the connections must be
freed/unrefed too.
The previous code often iterated over the collection first with
e.g. g_ptr_array_foreach and passing e.g. g_free as GFunc argument.
For one, this has the problem, that g_free has a different signature
GDestroyNotify then the expected GFunc. Moreover, this can be
simplified either by setting a clear function
(g_ptr_array_set_clear_func) or by passing the destroy function to the
free function (g_slist_free_full).
Signed-off-by: Thomas Haller <thaller@redhat.com>
Although it's convenient in some places to have IP configs on all
connections, it makes more sense in other places to not have IP
configs on slaves. (eg, it's confusing for nmcli, etc, to report a
full NMSettingIP4Config on a slave device). So revert parts of the
earlier patch. However, it's still safe to assume that s_ip4 != NULL
if method != DISABLED, so some of the earlier simplifications can
stay.
Also, add nm_utils_get_ip_config_method(), which returns the correct
IP config method for a connection, whether the connection has IP4 and
IP6 settings objects or not, and use that to keep some more of the
simplifications from the earlier patch.
Make sure that all connections returned from NMSettings or created via
AddAndActivateConnection have an NMSettingIP4Config and an
NMSettingIP6Config, with non-NULL methods, and get rid of
now-unnecessary checks for those.
Also move the slaves-can't-have-IP-config checks into the
platform-independent code as well. This also gets rid of spurious
"ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a
slave ifcfg file.
Partly based on a patch from Pavel.
https://bugzilla.gnome.org/show_bug.cgi?id=708875
