Use a GSList of the string values, instead of an array of GQuarks.
Using GQuarks does not allow to add arbitrary strings, because they
would leak the internalized strings. The next patch will begin
using unique, non-const action strings.
Given the rather small number of expected pending states, a singly
linked list seems appropriate.
Signed-off-by: Thomas Haller <thaller@redhat.com>
(some fixes and simplifications by dcbw based on patch reviews)
The NMActiveConnection class tracks the full activation request, and internal
activation requests go through the same process as external ones, including
some authentication. Sometimes that means activation is scheduled, control
returns to the mainloop, and then the activation proceeds from an idle
handler.
Unfortunately, that means that adding a pending "activation" action from
nm-device.c doesn't always work, since there is a short window between when
the activation is started in nm-manager.c (in nm_manager_activate_connection())
and when the device actually changes state. Inside that window, the pending
actions may drop to zero, and startup will be declared complete before the
device actually starts activating.
Instead, ensure that the pending action is added when the internal activation
is actually started (eg, when NMActiveConnection receives the NMDevice object).
Carrier state is only valid if the network interface is IFF_UP, because drivers
are not required to do carrier detection if the device is not up. Thus, if NM
is the first process to set the interface IFF_UP, there may be a short delay
while the driver performs carrier detection. NetworkManager must suppress
"startup complete" during this delay to ensure that the carrier state is known
before making startup property decisions.
Previously, when NetworkManager set the interface IFF_UP, the interface would
not have a carrier for a few seconds until the driver's carrier detection was
done. Since the interface had no carrier, NetworkManager could not begin
connection activation on the interface, and the interface would not suppress
the "startup complete" transition. Thus, NetworkManager would declare that
startup was complete prematurely and anything depending on startup network
connectivity would fail as no interfaces were active.
https://bugzilla.redhat.com/show_bug.cgi?id=1034921https://bugzilla.redhat.com/show_bug.cgi?id=1030583
This lets us do two things:
1) ensure that pending actions are unique and not doubly added/removed
2) we can (eventually) print out the pending action list for debugging
However, since we cannot have two pending actions with the same name at
the same time, we need to change the queued device state actions to
include the state name. But that makes debugging even more descriptive
so it's a bonus.
When a device is initialized to be managed, it will transition through states
unmanaged -> unavailable -> disconnected. We don't want to remove software
devices during this initial transition to disconnected, because it prevents
auto-activation.
Test case:
$ nmcli con add type vlan ifname myvlan dev eth0 id 123
NM should immediately create myvlan interface and automatically activate it.
https://bugzilla.redhat.com/show_bug.cgi?id=1035814
Slaves have no IP configuration and should not have any IP settings.
This fixes connection comparison between generated slave connections
and persistent slave connections, as persistent slave connections won't
have any IP configuration.
This reverts commit 9a019f1fb5.
Generic connections should be bound to their interface names in a more generic
way instead of in nm-device.c. The Generic device itself should set the
attributes it needs when generating the connection, like other device types do.
This will be done in a following commit.
Previously, the device activation would stall in this case, because
the code wasn't expecting it to happen. In particular, this happens
when trying to assume a device that is up but has no IP config.
https://bugzilla.gnome.org/show_bug.cgi?id=715181
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.
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
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.
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.
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.
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>
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.
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
To present a consistent API to clients, the IP-related properties
are only valid when the device has finished IP configuration. But
they are set before that happens, and their change notifications
were emitted before the IP configuration was considered valid.
Re-emit the change notifications when the device enters the IP_CHECK
state (and thus has IP configuration) and also when the device
deactivates to enusre clients have up-to-date IP-related property
information.
For the changes to has_ip_config(), the priv->ipX_state checks are
not necessary since the device will have valid IP configuration
when it enters the IP_CHECK state. The other checks can be
consolidated into a single statement.
Acked-by: Dan Winship
If the user disabled IPv6 support in the kernel with "ipv6.disable=1" on the
kernel boot line, then any attempts to open IPv6 sockets (which libndp does)
will fail. This failed the entire connection, even if IPv6's "may-fail"
property was TRUE. Instead, just fail IPv6 and allow IPv4 to proceed. If
IPv4 fails or is disabled, then other logic will fail the entire connection.
When the IP[46]Config changes, a new configuration gets assembled.
Before, whenever the new configuration was different than the current
one, the IP[46]Config of the device was completely replaced. This also
meant, that the old dbus IP[46]Config object was removed and the new one
was exported.
Now instead of recreating a new configuration, it updates the existing
(already exported) configuration in-place.
Also, add new gobject properties 'gateway' and 'searches' to the config class,
they will be exported over dbus.
Also, whenever any of the exported properties changes, make sure that a
notify signal gets emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=707617
Signed-off-by: Thomas Haller <thaller@redhat.com>
If there are no specs, then the device can't match, so don't call the
virtual method (which might do work like building comparison strings
even when the list is empty).
