nm_setting_bond_add_option returns TRUE or FALSE indicating, whether
the bond option was properly set. So, the API already kind of expects
invalid values, so there is no reason to warn about it.
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
NMSettingConnection was making sure that bond slaves didn't have an IP
configuration, but it should have been making that check for bridge
and team slaves too.
Several settings types' verify() functions need to find a particular
setting from the all_settings list that NMConnection passes them. Add
a convenience function for this.
When freeing one of the collections such as GArray, GPtrArray, GSList,
etc. it is common that the items inside the connections must be
freed/unrefed too.
The previous code often iterated over the collection first with
e.g. g_ptr_array_foreach and passing e.g. g_free as GFunc argument.
For one, this has the problem, that g_free has a different signature
GDestroyNotify then the expected GFunc. Moreover, this can be
simplified either by setting a clear function
(g_ptr_array_set_clear_func) or by passing the destroy function to the
free function (g_slist_free_full).
Signed-off-by: Thomas Haller <thaller@redhat.com>
gtk-doc recognizes that #NMFoos is the plural of #NMFoo now, so you
don't need to put an empty comment between the type name and the "s"
to make it work. (Unfortunately, it's not smart enough to realize that
"NMIP4Addresses" is the plural of "NMIP4Address".)
Also, add some missing "#"s noticed along the way.
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.
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.
'security' property is redundant, because the security restrictions are easily
recognized by the presence of '802-11-wireless-security' in a Wi-Fi connection.
The setting has to be present anyway, but we also had to set and check whether
the value in 'security' matches the security setting.
Following the KISS principle, it is best not to use the 'security' property
altogether.
Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
variables, which $(INCLUDES) did not, so this requires some additional
changes.
In most places, I have just gotten rid of the per-target _CPPFLAGS
variables; in directories with a single target, the per-target
variable is unnecessary, and in directories with multiple targets, the
per-target variable is often undesirable, since it forces some files
to be compiled twice, even though there ends up being no difference
between the two files.
If BOOTPROTO is set to "none", user states that no ipv4 setting should
be set. So respect that.
Introduce helper is_any_ip4_address_defined() along the way to make the
code more readable.
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
To better handle broken hardware, like switches which don't pass
traffic for a few seconds after a carrier has been negotiated,
add a timeout to control how long to wait for successful pings
of the gateway before giving up and proceeding with IP config.
Default is 0, which means don't ping the gateway, just assume
the NIC/switch aren't lying and can pass traffic immediately.
Add nm_utils_hwaddr_ntoa_len() and nm_utils_hwaddr_aton_len(), which
take a length rather than a type, which is generally more convenient,
and also necessary if you might be encountering devices of unknown
types.
When requesting connections to ModemManager, NetworkManager shouldn't try to
request specific bands or network types to use. Leave those requests to other
system configuration tools talking directly to ModemManager.
https://bugzilla.gnome.org/show_bug.cgi?id=701504
