Valid values for enumeration-style properties are offered in TAB-completion in
the editor. Thus the user has a quick overview of the possible values and can
edit properties more easily.
Example:
$ nmcli con edit type wifi
nmcli> set wifi-sec.group <TAB>
ccmp tkip wep104 wep40
nmcli> ...
https://bugzilla.redhat.com/show_bug.cgi?id=1034126
(cherry picked from commit 79bc271685)
nmcli 802-11-wireless.mode> set
Allowed values for 'mode' property: infrastructure, adhoc, ap
Enter 'mode' value:
(cherry picked from commit db0f5b3b4c)
NetworkManager only responds to the last D-Bus call when called delete/down
for the same connection in quick succession. (It should be fixed later).
So do not issue the call multiple times to prevent that. Otherwise nmcli would
stall waiting for the response.
https://bugzilla.redhat.com/show_bug.cgi?id=1168657
(cherry picked from commit f52e6bbdda)
Let the server decide which device to use if the user didn't explicitly
specify the interface, wireless access point or a wimax nsp.
The server will just reuse the device for an already active connection
or potentially do a better guess.
https://bugzilla.gnome.org/show_bug.cgi?id=730492
(cherry picked from commit 0e8a14cc5f)
Add new capabilities CAP_FREQ_2GHZ and CAP_FREQ_5GHZ to indicate the
frequency bands supported by a Wifi device.
Add also CAP_FREQ_VALID, which is set when the values of the other 2
capabilities are available.
Original patch by Dan Williams <dcbw@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=723295
(cherry picked from commit aabc6fc57b)
The following must not be allowed:
$ nmcli connection modify apath /org/freedesktop/NetworkManager/ActiveConnection/0
(cherry picked from commit 3cbce6994a)
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>
(cherry picked from commit 5ef233936a)
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...".
(cherry picked from commit bcd5b2cdc1)
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
