nmcli closes its stdout when spawning the pager and thus, in editor
mode, nothing is printed once the pager terminates. For an interactive
mode like the editor, the pager seems not suitable, disable it.
Fixes: 24c079e4b2
Branch f9b1bc16e9 added bluetooth NAP
support. A NAP connection is of connection.type "bluetooth", but it
also has a "bridge" setting. Also, it is primarily handled by NMDeviceBridge
and NMBridgeDeviceFactory (with help from NMBluezManager).
However, don't let nm_connection_get_connection_type() and
nm_connnection_is_type() lie about what the connection.type is.
The type is "bluetooth" for most purposes -- at least, as far as
the client is concerned (and the public API of libnm). This restores
previous API behavior, where nm_connection_get_connection_type()
and nm_connection_is_type() would be simple accessors to the
"connection.type" property.
Only a few places care about the bridge aspect, and those places need special
treatment. For example NMDeviceBridge needs to be fully aware that it can
handle bluetooth NAP connection. That is nothing new: if you handle a
connection of any type, you must know which fields matter and what they
mean. It's not enough that nm_connection_get_connection_type() for bluetooth
NAP connectins is claiming to be a bridge.
Counter examples, where the original behavior is right:
src/nm-manager.c- g_set_error (error,
src/nm-manager.c- NM_MANAGER_ERROR,
src/nm-manager.c- NM_MANAGER_ERROR_FAILED,
src/nm-manager.c- "NetworkManager plugin for '%s' unavailable",
src/nm-manager.c: nm_connection_get_connection_type (connection));
the correct message is: "no bluetooth plugin available", not "bridge".
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: if ( ( nm_connection_is_type (connection, NM_SETTING_WIRED_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: && !nm_connection_get_setting_pppoe (connection))
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_VLAN_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_WIRELESS_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_INFINIBAND_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_BOND_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_TEAM_SETTING_NAME)
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c: || nm_connection_is_type (connection, NM_SETTING_BRIDGE_SETTING_NAME))
src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-writer.c- return TRUE;
the correct behavior is for ifcfg-rh plugin to reject bluetooth NAP
connections, not proceed and store it.
This is useful because bond gets its mac from first slave and order of
slave attachement is not guaranteed.
For example if we have bond with wifi and ethernet we want mac from
wifi to be use by bond interface because many wifi defices do now
allow one to send data with spoofed macs.
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
Ethernet settings for VLAN are always created later in settings
normalization. We might as well always created them.
This fixes a user visible problem: currently if user specifies cloned
mac when connection is created this value doesn't get saved. User has
to go, edit saved connection to add it again.
Similar problem existed for wireless security and wifi
Signed-off-by: Nikolay Martynov <mar.kolya@gmail.com>
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 way, we get tab completion for the enum values, and
can reuse existing code.
This requires a pre-set-notify hook, that is invoked before
setting the property.
Instead of having 3 implementations for setting an int (int, uint, int64), combine
them. Also, make them more configurable by allowing to specify min/max/base, outside
of GParamSpec.
This makes it a lot more convenient to deal with long outputs (such as
"nmcli c show id ...").
The implementation is essentially jacked from systemd. The bugs are
mine.
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.
Now that routes can include optional attributes, print the expected
syntax in case of parsing failure.
$ nmcli connection modify dummy ipv4.routes a
Error: failed to modify ipv4.routes: invalid route: Invalid IPv4
address 'a'. The valid syntax is: 'ip[/prefix] [next-hop] [metric]
[attribute=val]... [,ip[/prefix] ...]'.
