$ nmcli connection down p
path
Connection 'p' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
Don't do completion when not requested.
We also do this for libnm, where it causes visible changes
in behavior. But if somebody would rely on the hashing implementation
for hash tables, it would be seriously flawed.
Next we will use siphash24() instead of the glib version g_direct_hash() or
g_str_hash(). Hence, the "nm-utils/nm-hash-utils.h" header becomes very
fundamental and will be needed basically everywhere.
Instead of requiring the users to include them, let it be included via
"nm-default.h" header.
Change the activation procedure for connections that require secrets
in the following way:
- nmcli creates a secret-agent and leaves it disabled so that
incoming requests are queued
- nmcli calls ActivateConnection()
- when the method returns success, the secret-agent gets enabled and
all queued requests are processed
When the user activates a connection which is already auto-activating,
NM will deactivate the current active-connection and will call
CancelGetSecrets() for it before the new ActivateConnection()
returns. In this way, when the secret-agent is enabled by nmcli, we
have the guarantee that there aren't any queued requests for
the deactivating connections.
https://bugzilla.redhat.com/show_bug.cgi?id=1438476
nmc_read_connection_properties() iterates over the input arguments, and
completes the connection.
Initially, the type is not yet known, in that case, we should not wrongly
assume that this is a generic connection. Later, when the type is specified,
con_settings() will return the correct settings.
Previously, this would wrongly add a [generic] section:
$ nmcli connection add type ethernet ifname eth1 con-name ethie autoconnect no ipv4.method auto ethernet.cloned-mac-address random
With the fix, it still works to specify the type later:
$ nmcli connection add ifname eth1 con-name ethie autoconnect no ipv4.method auto type ethernet
but it doesn't work, to specify the type after type-specific options:
$ nmcli connection add ifname eth1 con-name ethie autoconnect no ipv4.method auto ethernet.cloned-mac-address random type ethernet
Error: invalid or not allowed setting 'ethernet': 'ethernet' not among [connection, ipv4, ipv6, proxy].
The patch doesn't change the latter limitation.
Fixes: c5324ed285
Replace the usage of g_str_hash() with our own nm_str_hash().
GLib's g_str_hash() uses djb2 hashing function, just like we
do at the moment. The only difference is, that we use a diffrent
seed value.
Note, that we initialize the hash seed with random data (by calling
getrandom() or reading /dev/urandom). That is a change compared to
before.
This change of the hashing function and accessing the random pool
might be undesired for libnm/libnm-core. Hence, the change is not
done there as it possibly changes behavior for public API. Maybe
we should do that later though.
At this point, there isn't much of a change. This patch becomes
interesting, if we decide to use a different hashing algorithm.
In a later commit we'll add a new generic client function used by
nmcli and nmtui. nm-client-utils.c seems the right place for it, so
move the file to the base library that is used by both clients.
While at it, also put in that file some functions that will be needed
by nmtui.
As far as NetworkManager is concerned, the "connection.id" (also called
"con-name" in nmcli) is a pretty name and does not need to be unique.
UI components usually show the "connection.id" instead of the
"connection.uuid" identifier. It is hence likely, that the user
would not intentionally re-use the same name for multiple connection
profiles.
Print a warning to stderr when the user adds such a connection.
This only affects `nmcli connection add` and `nmcli connection import`,
but not `nmcli connection clone` and not interactive edit mode.
https://bugzilla.redhat.com/show_bug.cgi?id=1460796
Currently nmcli considers the state of the device associated to a
connection to determine the success of an activation; for VPNs the
device is the parent interface on which the VPN is established.
This means that VPNs on bond/bridge/team interfaces are reported as
connected immediately because of the special handling of master
devices state in check_activated().
The parent device state is not meaningful for VPNs, so don't track it.
Since properties are asked only when the connection has the related
setting, ensure that the connection type is set early so that the base
type gets added to the connection before evaluating other settings.
After NMSettingConnection properties, ask properties for the base
setting and then all other settings.
In the previous code it is not clear to me that there won't be
a situation where we don't react on a state change, waiting for a
device-state-change that never comes.
Now, only wait for a better device-state reason if:
- we have a device
- and the ac-reason is unspecific (NM_ACTIVE_CONNECTION_STATE_REASON_DEVICE_DISCONNECTED)
- and the device still references the current active connection
- and the device state is not yet FAILED or DISCONNECTED.
The most important change is that we only wait longer, if the device's
active-connection is still the same as our current active connection.
I don't think this commit is really necessary, but I cannot understand
the previous logic.
See-also: 57a26fd2aa
This basically uses "wifi" in place of "802-11-wireless" and analogously
for other setting types that have aliases unless a --terse option was
specified.
Apart from looking nicer it makes the default output less wide,
hopefully avoiding line breaks on 80 column terminals in basic use
cases.
'nmcli connection show <con_id1> --show-secrets'
secrets were not shown.
'nmcli connection show <con_id1> --show-secrets <con_id2>'
secrets were shown only for connection ids following the
"--show-secrets" option (so only for 'con_id2').
Fix these behaviors showing secrets for all connections also
if the "--show-secrets" option is put after the connection ids.
If the D-Bus call to DeactivateConnection() fails, don't wait for the
connection to change state because this is not going to
happen. Instead, notify the user of the error and, if necessary, wait
for remaining connections to be deactivated.
https://bugzilla.redhat.com/show_bug.cgi?id=1422786
That allows for the property list to contain derived
property types. Also, the list can be directly passed
off as a "const NMMetaAbstractInfo *const*" list.
This change (improves) behavior.
Before, we would only complete
if (g_strcmp0 (con_type, nmc_tab_completion.con_type) != 0)
which doesn't really make sense as it depends on the slave-type,
not nmc_tab_completion.con_type.
This changes behavior, in that yes|no prompt and answer is no longer
localized.
For command line arguments, I think it is always wrong for nmcli to
behave differently based on the localization. That is, input properties
on command line should not be translated.
One could make an argument, that in interactive mode that is different
and the user can be prompted in the his language.
But I think for consistency, it is wrong to ask for localized nmcli input.
Don't mutate global state. For now, hack around it by putting
the mutable flags to a separate (global) cache. Obviously, it
still uses global data, but it no longer touches the global
option_info list.
