_init_completion returns the '${words[@]}' array with all the
quotes and escapes. We dont care about it so we drop (unescape)
first.
Before, the following failed:
nmcli 'c' <TAB>
nmcli connection modify id Wireless\ Connection\ 1 <TAB>
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.
Move the checks for nmc_arg_is_help to the beginning of the
checks for command matches.
Up to now, no command begins with 'h', so this has no behavioral
change whatsoever. But imagine a command that begins with 'h'
(for example `nmcli general hostname`), in that case `nmcli general h`
should still show the help, as users might be accustomed to this
abbreviation.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Ensure in matches() that a non-empty cmd is given, otherwise
as currently
nmcli general -
matches to '-h' and is thus treated as
nmcli general -h
Signed-off-by: Thomas Haller <thaller@redhat.com>
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.
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>
