A few examples:
nmcli --ask connection add
nmcli connection add type ethernet
nmcli -p connection add type ethernet con-name "my ethernet connection 1"
nmcli connection add type ethernet ip4 192.168.100.5/24
nmcli connection add type ethernet ip4 192.168.100.100/24 gw4 192.168.100.1 ip4 1.2.3.4 ip6 abbe::cafe
nmcli connection add type ethernet ifname eth0
nmcli connection add type ethernet autoconnect no ifname eth0
nmcli connection add type wifi con-name Rakosnicek ssid Brcalnik
nmcli --ask connection add type wifi con-name My_WiFi
nmcli c a type infiniband con-name Infi1 transport-mode connected
nmcli c a type bluetooth addr 12:54:00:fd:db:26
nmcli c a type bluetooth addr 12:54:00:fd:db:26 bt-type dun-cdma
nmcli c a type gsm apn internet
nmcli c a type cdma
nmcli c a type bond
nmcli c a type bond ifname mybond0 mode active-backup
nmcli c a ifname maxipes-fik type vlan dev eth0 id 55
nmcli c a con-name VLAN1 type vlan dev eth0 id 44 ingress "2:4,3:55" egress "1:3" flags 6
nmcli c a type bridge ifname br0 stp on ip4 10.0.0.25
nmcli c a ifname eth0 type bridge-slave master 30fc816a-e7dd-4ae7-a86e-ab0c9cee51c2 hairpin no path-cost 333 priority 20
nmcli c a type bridge-slave master br2
If there are no slaves after the timeout, exit nmcli with an error, assuming
that NM is waiting for slaves to finish activation:
"(bondx) "IPv4 config waiting until slaves are ready"
"(bondx) "IPv6 config waiting until slaves are ready"
The static connection profiles are 'configured'.
So, now we have:
nmcli connection show configured [[id|uuid|path] <ID>]
- shows configured connections
nmcli connection show active [[id|uuid|path|apath] <ID>]
- shows active connections
Without arguments the commands list all connections; with an argument, the details
of the requested connection is shown.
and also allow identifying connetions with 'path' and 'apath' that accepts either
the whole D-Dus path or just an index.
nmcli connection down [id|uuid|path|apath] <ID>
Example:
nmcli connection down con1
nmcli connection down con1 con2 apath 1 id my-wifi
and also allow identifying connetions with 'path' that accepts either the whole
D-Dus path or just an index.
nmcli connection up [id|uuid|path] <ID>
Examples:
nmcli connection up "My Home Wi-Fi"
nmcli connection up id "My Home Wi-Fi"
nmcli connection up path /org/freedesktop/NetworkManager/Settings/18
nmcli connection up path 18
Note:
In order to be able to identify connections with just index number, the 'path'
keyword has to be provided.
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.
