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.
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().
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>
The NMPlatformIP[46]Address and NMPlatformIP[46]Route structs have a
field 'dev'. Before this field was always printed in the *_to_string
functions and a missing device was signaled as ' dev -'.
This had the advantage, that the output contained the same fields
regardless whether there was a device set or not.
Change it, not to print the device if it is not set. This has the
advantage, that it looks better in the logfiles.
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>
nm_connection_dump is mainly used for printf debugging, so
no need about being overly critical about not accepting NULL.
Just don't dump anything.
Signed-off-by: Thomas Haller <thaller@redhat.com>
In the case of autoconnect VLANs or IB partitions, if the parent interface
hasn't been detected yet at startup, then the get_virtual_interface_name()
won't be able to find the parent yet. That's normal, and when the parent
is found, system_create_virtual_device() will be run again and the parent
will be found, and the autoconnect VLAN/IB partition will be created.
But we shouldn't warn that the parent can't be found when that might be
a normal occurance.
Also improve nm_ip4_config_dump to print all properties and make
use of nm_platform_*_to_string.
Also, ensure that never_default is set to gboolean 1 or 0.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Do some minimal verification of hostnames that come in via D-Bus, for
length and content. Otherwise we'd get as far as asking glibc to set
the system hostname, which would reject us.
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.
This had the side-effect of auto-activating DHCP connections on
ignore-carrier devices that didn't have a carrier, if that device had at
least one static IP connection available. Not good.
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.
https://bugzilla.gnome.org/show_bug.cgi?id=710216
