Looks more like 5, not 7, unless a particular mode is selected:
There are 7 optional arguments for 'bond' connection type.
Do you want to provide them? (yes/no) [yes]
Bonding mode [balance-rr]:
Bonding monitoring mode (miimon/arp) [miimon]:
Bonding miimon [100]:
Bonding downdelay [0]:
Bonding updelay [0]:
Previously we would only complete connections given by ID.
The following would work:
$ nmcli connection modify id <ID> <TAB>
$ nmcli connection modify <ID> <TAB>
$ nmcli connection modify uuid <UUID> <TAB>
but the following would not work:
$ nmcli connection modify <UUID> <TAB>
Error: DEADCODE (CWE-561): [#def3]
NetworkManager-0.9.11.0/clients/cli/utils.c:488: cond_notnull: Condition "input", taking true branch. Now the value of "input" is not "NULL".
NetworkManager-0.9.11.0/clients/cli/utils.c:517: notnull: At condition "input", the value of "input" cannot be "NULL".
NetworkManager-0.9.11.0/clients/cli/utils.c:517: dead_error_condition: The condition "input" must be true.
NetworkManager-0.9.11.0/clients/cli/utils.c:517: dead_error_line: Execution cannot reach the expression """" inside this statement: "g_set_error(error, 1U, 0, d...".
nmcli currently does not wait for the connection to fully deactivate, which
can take some time due to dispatcher scripts or cleanup operations like
DCB. Change it to wait until the connection is deactivated, or until
a short timeout has expired. The user can adjust the timeout with
"--wait" if they want.
https://bugzilla.gnome.org/show_bug.cgi?id=740775https://bugzilla.redhat.com/show_bug.cgi?id=1168383
set_connection_path() is almost always called right before enable(),
and it's unclear why it would be called anywhere else. So just
merge the two methods.
nm_secret_agent_simple_*() functions should take an
NMSecretAgentSimple, not an NMSecretAgent.
The type macros were incorrectly validating against
NM_TYPE_SECRET_AGENT rather than NM_TYPE_SECRET_AGENT_SIMPLE.
If we're activating the device without knowing the connection in advance, defer
servicing the requests for the secrets until we set the path.
[lkundrak@fedora20-2 ~]$ nmcli --ask c ifname wlan0
(process:18405): libnm-CRITICAL **: nm_object_get_path: assertion 'NM_IS_OBJECT (object)' failed
Error: Connection activation failed: The device has no connections available.
[lkundrak@fedora20-2 ~]$
The signals might be delivered in no particular order and we need to wait for
the device to reach stable state (whether it's successfully conntected or not)
as well as the active connection to leave ACTIVATING state.
https://bugzilla.gnome.org/show_bug.cgi?id=740320
Now that nm-setting-docs.xml is more D-Bus-specific, it's less
appropriate for nmcli's internal documentation. So generate a second
copy of the docs without using the overrides file, and use that one
for nmcli's documentation.
Move the settings/plugins doc generation from libnm-util to
libnm-core, since libnm-util isn't being updated for all new
properties.
With this commit, the keyfile and ifcfg-rh documentation is basically
unchanged, except that deprecated properties are now gone, and new
properties have been added, and the sections are in a different order.
(generate-plugin-docs.pl just outputs the settings in Makefile order,
and they were unsorted in libnm-util, but are sorted in libnm-core).
The settings documentation used for nm-settings.5, the D-Bus API docs,
and the nmcli help is changed a bit more at this point, and mostly for
the worse, since the libnm-core setting properties don't match up with
the D-Bus API as well as the libnm-util ones do. To be fixed...
(I also removed the "plugins docs" line in each plugin docs comment
block while moving them, since those blocks will be used for more than
just plugins soon, and it's sort of obvious anyway.)
The device status alone is uninteresting as its changes can be due to
deactivation of previously active connection. We should monitor the
active connection changes instead of device state changes.
However the device state changes is still interesting, as it contains the
reason for the change, let's just ignore them while the connection is
activating.
Lastly, we need to handle failures as well. It should be noted that it's
not sufficient to deal with NM_DEVICE_STATE_FAILED as the device will
quickly draverse to NM_DEVICE_STATE_DISCONNECTED. This happens in case of
a failure due to NM_DEVICE_STATE_REASON_NO_SECRETS as soon as the server
makes sure it won't reconnect automatically.
docs/api/settings-spec.xml was accidentally not getting disted,
because gtk-doc.make explicitly removes all DISTCLEANFILES from
distdir. However, it doesn't actually make sense for the settings docs
files to be in DISTCLEANFILES anyway; they were put there rather than
CLEANFILES (IIRC) so that "make clean" in a tarball build wouldn't
delete them and break things. But the right fix is to just make them
only be in CLEANFILES when BUILD_SETTING_DOCS is true, and not ever
get deleted otherwise.
Also adjust the build rules to ensure that the generated docs don't
get rebuilt in tarball builds, since that can cause problems when
building from a read-only source tree, etc.
Meanwhile, in an unrelated but also fatal bug, configure.ac's check
for if the generated docs were already present never got updated for
the cli/src -> clients/cli move, and so even if we had been disting
settings-spec.xml, configure would still think that the tarball didn't
have all of the generated docs in it, so SETTING_DOCS_AVAILABLE would
be set false and none of the generated docs would get used.
https://bugzilla.gnome.org/show_bug.cgi?id=740035
When wifi secrets are missing, NM_DEVICE_STATE_FAILED due to
NM_DEVICE_STATE_REASON_NO_SECRETS is immediately followed by traversal to
NM_DEVICE_STATE_DISCONNECTED as soon as the server makes sure it won't
reconnect automatically. We sometimes aren't quick to handle the first signal
and only get the latter one.
Let's treat all states that aren't ordinarily reached upon activation as bad.
When a connection is being activated, nmcli could ask for secrets for another
connection, which might confuse users. We check the request now and only ask
for secrets of connection being activated.
Test case:
$ nmcli con up my-ethernet0
Passwords or encryption keys are required to access the wireless network 'Red Hat'.
Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli cannot ask without '--ask' option.
$ nmcli dev disconnect nm-bond
Error: Timeout 10 sec expired.
When a software device is disconnected, it will be removed. And it may not go
to NM_DEVICE_STATE_DISCONNECTED state before that. So we need to listen to
"device-removed" signal.
Fixes:Beaker:test_log-NetworkManager_Test189_bond_activate
Make the type return GBytes since most in-tree users want that.
Allow the function to accept many more formats as valid hex, including
bytes delimited by ':' and a leading '0x'.
Create NMIPConfig as the parent of NMIP4Config and NMIP6Config, and
remove the two subclasses from the public API; while it's convenient
to still have both internally, they are now identical to the outside
world.
The gateway is a global property of the IPv4/IPv6 configuration, not
an attribute of any particular address. So represent it as such in the
API; remove the gateway from NMIPAddress, and add it to
NMSettingIPConfig.
Behind the scenes, the gateway is still serialized along with the
first address in NMSettingIPConfig:addresses, and is deserialized from
that if the settings dictionary doesn't contain a 'gateway' key.
Adjust nmcli's interactive mode to prompt for IP addresses and gateway
separately. (Patch partly from Jirka Klimeš.)
Now that NMSettingIP6Config inherits the dhcp-send-hostname property
from NMSettingIPConfig, fix things up so that it actually gets used.
(Note that this changes behavior: previously if ip6.dhcp-hostname was
unset, no hostname would be sent. Now, the system hostname will be
set. Also, ifcfg-rh does not currently support this property, so there
is no way to disable this...)
Split a base NMSettingIPConfig class out of NMSettingIP4Config and
NMSettingIP6Config, and update things accordingly.
Further simplifications of now-redundant IPv4-vs-IPv6 code are
possible, and should happen in the future.
Merge NMIP4Address and NMIP6Address into NMIPAddress, and NMIP4Route
and NMIP6Route into NMIPRoute. The new types represent IP addresses as
strings, rather than in binary, and so are address-family agnostic.
Synopsis:
nmcli agent { secret | polkit | all }
The command runs separate NetworkManager secret agent or session polkit agent, or both.
It is useful when
- no other secret agent is available (such as GUI nm-applet, gnome-shell, KDE applet)
- no other polkit agent is available (such as polkit-gnome-authentication-agent-1,
polkit-kde-authentication-agent-1 or lxpolkit)
https://bugzilla.gnome.org/show_bug.cgi?id=739568
It is useful for running nmcli without --ask option, i.e. non-interactively.
Example contents of the file:
wifi.psk: s e c r e t 12345
802-1x.password:kili manjaro
802-1x.pin:987654321
