IPoIB "hardware addresses" are only partly based on the hardware, and
partly based on the InfiniBand configuration. So when checking if a
configuration matches a device, we should only match the fixed part.
Fix infiniband_partition_add() to put the newly-created device into
the link_cache before returning. Fix link_is_software() to recognize
partition devices as software, so that link_get() is willing to return
them even before we get the udev info.
If there are no specs, then the device can't match, so don't call the
virtual method (which might do work like building comparison strings
even when the list is empty).
The problem is that there is only a single variable in ifcfg file holding dns
domains - DOMAIN. Thus NetworkManager writes both IPv4 and IPv6 dns-search into
it. While reading there is no way to distinguish between IPv4 and IPv6 values,
so the DOMAIN value is read and only put into IPv4 dns-search.
But, when IPv4 is disabled or invalid, the domains got lost. So in such case
we put DOMAIN variable into IPv6 instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1004866
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.
