These are expected errors if the supplicant can't be launched
for some reason. We should only log entirely unexpected errors
like wrong method arguments or types, really odd failures, etc.
NetworkManager[1312]: <error> [1379601146.148818] [supplicant-manager/nm-supplicant-interface.c:853] interface_add_cb(): (wlan0): error adding interface: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
NetworkManager[1312]: <error> [1379601171.160742] [supplicant-manager/nm-supplicant-interface.c:853] interface_add_cb(): (wlan0): error adding interface: Activation of fi.w1.wpa_supplicant1 timed out
Bonding options are related and some combinations don't make sense. Basically,
MIIMON and ARP monitoring mode (and related options) are mutually exclusive.
When nmcli set arp_interval of "0" (the default value),
nm_setting_bond_add_option() cleared the MIIMON options (miimon, updelay and
downdelay).
This commit works around libnm-util's nm_setting_bond_add_option() that clears
miimon options when arp_interval is being set and vice versa, but doesn't
take into account the value of "0" that should be regarded as 'disable'.
https://bugzilla.redhat.com/show_bug.cgi?id=1007355
The commands performing actions without an output only printed a successfull
message for --pretty mode. Some users don't like this silent operation.
This commit makes nmcli print operation success unconditionally. I think that
doesn't hurt; scripts/users can ignore the message if not interested.
https://bugzilla.redhat.com/show_bug.cgi?id=1006444
Also allow leading/trailing white spaces, and more white spaces between IP and
gateway. (Spaces in values and around / are not allowed).
All of these are accepted:
' 1.2.3.4/11 1.2.3.254 '
' 1.2.3.4 '
' fe80::215:ff:fe93:ffff/128 ::1 '
...
https://bugzilla.redhat.com/show_bug.cgi?id=1007368
Since 2688ae4950, bridge device creation
fails with "(br0): cannot use existing bridge for 'Bridge'" warning.
Signed-off-by: Thomas Haller <thaller@redhat.com>
The format of property values that nmcli prints is not the same (for some
properties) as the format nmcli editor accepts as input from user. The reasons
are that (a) output format is more descriptive and not much suitable to be
typed, (b) it comes in most cases from libnm-util.
'change' command displays current property value and allows users to edit it.
So we convert the output into input format, before presenting it to the user.
https://bugzilla.redhat.com/show_bug.cgi?id=998929
Currently, ethernet-based VLANs can specify the hardware address of
the parent device (and, in theory, the cloned hardware address and MTU
of the VLAN device) by using an NMSettingWired in addition to the
NMSettingVlan.
The theory was that non-ethernet-based VLANs, when we eventually
supported them, would likewise use the setting type corresponding to
their parent device. However, this turns out to be both complicated
(the settings plugins and connection editor would have a
hard-to-impossible time figuring out which setting type to use in some
cases) and incorrect (for most L2 settings [eg, BSSID, bond mode,
etc], the VLAN can't have its own values separate from the parent
device).
What we should have done was just have :mac-address,
:cloned-mac-address, and :mtu properties on NMSettingVlan. However, at
this point, for backward-compatibility, we will just stick with using
a combination of NMSettingVlan and NMSettingWired, but we will use
NMSettingWired regardless of the underlying hardware type.
Rather than having NMManager know how to parse various settings to
create each kind of software device, add a _new_for_connection()
constructor to each of them and let them call NMPlatform to create the
device correctly themselves.
Rather than setting the VLAN maps when the device is created, set them
at activation time, which is more in line with how other device types
work.
Like the old code, this doesn't attempt to reset any existing
ingress/egress mappings on the device.
readline() makes changes to terminal and when it doesn't receive unix signals,
it has no chance to perform cleanups on exit. So we have to call its cleanup
functions manually on exit.
https://bugzilla.gnome.org/show_bug.cgi?id=706118
If you called nm_remote_connection_delete() on a connection whose only
ref was held by the NMRemoteSettings, then the callback would never
get called, because NMRemoteSettings would drop its ref before then
(when the connection emitted the 'removed' signal), so the callback
would get cancelled.
Fix this by taking an extra ref on the connection around the D-Bus
call in this case.
https://bugzilla.redhat.com/show_bug.cgi?id=997568https://bugzilla.gnome.org/show_bug.cgi?id=706141
Old versions such as 0.9.4 generated 40-character UUIDs with no
hashes, but libnm-util regards them as invalid. That means that
existing connections stop working when upgrading from 0.9.4.
Continue accepting such UUIDs as valid, and add a test so that
we don't forget in future.
They look exactly like normal Ethernet interfaces, but they are managed
entirely by the Open vSwitch tools in software, so NM shouldn't (yet)
touch them. Treat them instead as generic devices that only get touched
through direct user requests.
- the ifname argument for "connection add" is not mandatory
- support the long names for connection types ("802-*")
Signed-off-by: Thomas Haller <thaller@redhat.com>
