and also allow identifying connetions with 'path' that accepts either the whole
D-Dus path or just an index.
nmcli connection delete [id|uuid|path] <ID>
Example:
nmcli connection delete "Wired 1" "Wired 2" "Wired 3"
nmcli connection delete id MyMain id "Quick Test 1" "Quick Test 2" path 23 path 47
And also allow:
- identifying connetions with 'path'/'apath' accepting either the whole D-Dus path
or just an index
- multiple connections on cmdline at once
nmcli connection list [[id|uuid|path] <ID>]
nmcli connection status [[id|uuid|path|apath] <ID>]
Examples:
nmcli c l
nmcli c l "My Wi-Fi 1" airpoirt1 cpath 23 id "My Wi-Fi 2"
nmcli c s
nmcli c s apath 1 ee19b893-e2a7-42cf-ac82-34506f07a05f
libnm-glib handles connecting to the bus automatically if NULL
is passed for the bus object. Do that; plus this lets us use
the private bus connection if present.
Shorter forms work as previously. Thus, all of these commands are valid:
nmcli device, nmcli devic, nmcli devi, nmcli dev, nmcli de, nmcli d
nmcli connection, nmcli connectio, ..., nmcli conn, nmcli con, ..., nmcli c
This can happen e.g. when D-Bus limits number of replies and there's
a lot of connections. Then nm_remote_settings_list_connections() won't
return all connections and the connection that was activated can be among
the missing connections.
When '-nocheck' option was used, NMClient object was created later in the
operation process.
This caused that the callback in nm_client_activate_connection() was not
called. It's fixed by creating NMClient early.
We need to use a workaround for VPN connection state. There is a bug somewhere
causing that vpn-state-changed signal is not issued on active VPN connection.
Debugging showed that D-Bus PropertiesChanged and VpnStateChanged signals are
not processed properly. That's why libnm-glib's VPN connection object is not
updated. The issue may lie in libnm-glib or even in dbus-glib.
I wasn't able to get VpnStateChanged signal via dbus-glib
(dbus_g_proxy_add_signal() and dbus_g_proxy_connect_signal()), however received
the signal successfully using GDBus.
Until the issue is analyzed and fixed, we need to ask for VPN state of active
VPN connection every second in order to show progress and exit correctly.
Add nm_device_connection_compatible() that returns an error when it fails.
nm_device_connection_valid() does the same work except it doesn't set GError.
"InfiniBand" has a capital "B". Fix that everywhere it's being used as
a human-readable string.
In particular, the RH initscripts recognize "TYPE=infiniband" and
"TYPE=InfiniBand", but not "TYPE=Infiniband", which is what we were
writing before.
This is a proposal to include the NMActiveConnection master property in
nmcli con status.
Feel free to suggest a more user friendly method of printing this
information.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
The command didn't delete the connection, because nmcli exited before NM could
check permissions (actually ConsoleKit didn't see the process).
Now nmcli waits for "Removed" signal or D-Bus return (error) message on "Delete"
method call.
nm_access_point_get_hw_address() is deprecated in 0.9.
Also change 'hwaddr' parameter for 'nmcli dev wifi list' to 'bssid'. 'hwaddr'
still works but is deprecated and not documented any more.
nm_client_activate_connection() now uses NMConnection instead of
D-Bus connection path. Also, callback uses NMActiveConnection instead
of the path.
We can also remove the workaround waiting for "active-connections" change,
because the activation callback is now called *after* the NMActiveConnection
object is available in the active connections list.
These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc. The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want. There's a better way...
Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload. (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA). This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.
The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
