The non-"_t"-suffixed type names in gnutls have been deprecated since
1.x, and in recent versions will trigger deprecation warnings. Fix by
using "gnutls_datum_t" instead of "gnutls_datum".
This was added for debugging, but is no longer necessary.
Also, strace might not be installed on any system so don't depend on it.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This is the same behaviour as nm_utils_normalize_connection(),
which will soon be removed in favor of nm_connection_normalize().
This takes care, that normal connections always have an IP4 and IP6 setting,
and that slave connections never have it.
Signed-off-by: Thomas Haller <thaller@redhat.com>
- Before, when setting the slave-type to an invalid type, the setting
was silently accepted. Now verification fails with "Unknown slave type '%s'"
- Before, the @master property was not checked. So you could have a @slave-type,
without having @master set. And similarly, you could have @master, but
no @slave-type. Fix both issues.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Some type-specific NMSetting implementations (bond, bridge, team, vlan)
have their own 'interface-name' property. This property will be
deprecated in favour of 'interface-name' in NMSettingConnection.
Change verify() and normalize() to check that the redundant
values match and repair/normalize the properties.
Force the virtual interface name of the type-specific setting to be
equal to NMSettingConnection:interface_name. This way, the depreacted
field stays valid and backward compatible.
NMSettingInfiniband is special, because it does not have a backing
property for the interface name, although it implements
get_virtual_iface_name(). To account for this, some special handling
is needed in order not to change the behaviour of get_virtual_iface_name().
Signed-off-by: Thomas Haller <thaller@redhat.com>
This function behaves like verify(), but it also performs some
normalization/fixing of inconsistent connections.
Contrary to verify(), this function might modify the settings.
This will be mainly used, to repair connections from older versions
and to fix deprecated options.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Certain build configurations (like --enable-gtk-doc
--disable-introspection) were broken with respect to nm-setting-docs.
Fix this. Also, we don't require just gobject-introspection, we need
pygobject specifically as well.
Remove all remaining GParamSpec name and blurb strings (and fix
indentation while we're there), and add G_PARAM_STATIC_STRINGS to all
paramspecs that were lacking it.
Remove all the GParamSpec docs, since everything now uses the gtk-doc
docs instead, so there's no point in having two copies of each (which
are often out of sync anyway).
Since we're touching so many lines anyway, also fix up the indentation
of the remaining property-installing lines, and add
G_PARAM_STATIC_STRINGS to each paramspec (so the nick strings don't
get strduped). Also, be consistent about starting a new line between
"g_object_class_install_property" and its opening parenthesis.
Add generate-setting-docs.py, based on tools/generate-settings-spec.c,
which generates a simple XML file describing all libnm setting
properties (still getting the default values via GParamSpec
introspection like generate-settings-spec.c does, but getting the
documentation out of the gtk-doc strings in the GIR file instead).
Fix up various issues with the docs for the NMSetting properties, and
pull in text from the GParamSpec docs where the GParamSpec docs were
better (or contained information that is necessary in the context of
nm-settings.5).
Also, consistently wrap all of the doc comments to the same width (80
columns).
Fix misused gtk-doc annotations and incorrectly-identified properties.
In particular, the upcoming introspection-based generate-settings-spec
expands macro and enum values, so if you use '%' where you should have
used '#', it will fail to find an expansion, and error out.
We made the UIs consistent last year, but missed the documentation.
Fix the docs to also consistently use "Wi-Fi" rather than "WiFi",
"Wifi", "wifi", or "WiFI"; "Ethernet" rather than "ethernet"; and
"InfiniBand" rather than "Infiniband".
Some tests want to assert against the messages logged using g_test_expect_message().
In this mode, nmtst will not log anything itself.
Interpret the option no-expect-message which turns g_test_expect_message()
into a NOP and turns logging on. The use of this is for debugging such
tests, without asserting against the messages but printing them instead.
For tests that are not in the assert_message mode, the option has no
effect.
Example:
NMTST_DEBUG=debug,no-expect-message make -C src/settings/plugins/keyfile/tests/ check
Signed-off-by: Thomas Haller <thaller@redhat.com>
ipv4.never-default, ipv4.may-fail, and ipv6.privacy were marked
INFERRABLE, but NMIP4Config / NMIP6Config didn't actually infer them,
so they could cause connections to not match themselves after a
restart.
(Found while debugging https://bugzilla.redhat.com/show_bug.cgi?id=1086237,
though this is not actually the problem there.)
Related: rh#1086237
- nm_utils_hwaddr_len() and nm_utils_hwaddr_type() no longer assert
against known input types/lengths. Now they can be used to detect the
hwaddr type, returning -1 on unknown.
- more checking of input arguments in nm_utils_hwaddr_aton() and
related. Also note, that nm_utils_hwaddr_aton_len() has @len of type
gsize, so we cannot pass on the output of nm_utils_hwaddr_len()
without checking for -1.
Signed-off-by: Thomas Haller <thaller@redhat.com>
It happens when one selected private key, but didn't provide the password yet
in nm-connection-editor.
(nm-connection-editor:11080): libnm-util-CRITICAL **: crypto_md5_hash: assertion `password_len > 0' failed
This results in some nice coloring. Only move the tests that are called
without arguments from check-local to TESTS.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This is intended to contain utility functions for tests. It will
be header only (containing inline functions).
Signed-off-by: Thomas Haller <thaller@redhat.com>
Commit 240c92ddb5 added an assert
to check that the input netmask is valid. Revert that commit for
the most part, some changes to the test function are not reverted.
We don't want to assert for a valid netmask, because it's
common to read the netmask from (untrusted) user input, so we
don't want to assert against it.
The caller *could* validate the netmask from untrusted sources, but
with the assert in place it cannot validate it in the most obvious way:
prefix = nm_utils_ip4_netmask_to_prefix (netmask);
if (netmask != nm_utils_ip4_prefix_to_netmask (prefix))
goto fail;
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_setting_wired_remove_mac_blacklist_item_by_value()
Also add missing function nm_setting_wired_clear_mac_blacklist_items() and notify
about mac-address-blacklist changes.
Add versioned NM_DEPRECATED_IN_* and NM_AVAILABLE_IN_* macros, and tag
new/deprecated functions accordingly. (All currently-deprecated
functions are assumed to have been deprecated in 0.9.10.)
Add NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED macros which
can be set to determine which versions will cause warnings.
With the current settings, external consumers of the
libnm-util/libnm-glib APIs will have MIN_REQUIRED and MAX_ALLOWED both
set to NM_VERSION_0_9_8 by default, meaning they will get warnings
about functions added in 0.9.10. NM internally sets
NM_VERSION_MAX_ALLOWED to NM_VERSION_NEXT_STABLE to ensure that it is
always allowed to use all APIs.
Given an IPv4 address and prefix for a shared config, figure out
the DHCP address range automatically. To keep things simple we
allow a max of 252 addresses (not including network address,
broadcast address, and the hotspot) no matter what prefix you use,
so if the address is 10.0.10.1, you still only get a range of
10.0.10.2 -> 10.0.10.254.
But we also leave some addresses available above the host address
for static stuff, like we did before. This is done on a sliding
scale from 0 to 8 addresses, where about 1/10th the number of
available addresses are reserved.
https://bugzilla.gnome.org/show_bug.cgi?id=675973
This changes behaviour of nm_connection_update_secrets() in that it will
now return %TRUE, if there are no secrets to be cleared. Seems more
correct, to return success if there is nothing to do.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Often, nm_connection_clear_secrets does have no consequences, because
there is nothing to be cleared. Only raise a signal, if something
actually changed.
Signed-off-by: Thomas Haller <thaller@redhat.com>
- use a more efficient implementation for prefix_to_netmask
- fix netmask_to_prefix to behave consistently in case of
invalid netmask
- remove unused duplicated functions from NetworkManagerUtils.c
- add test functions
Based-on-patch-by: Pavel Šimerda <psimerda@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
Related: https://bugzilla.gnome.org/show_bug.cgi?id=721771
- refactor register_settings to allow lookup by GType and
add the settings name to SettingInfo.
- setting NM_SETTING_NAME is deprecated and should not be set anymore.
Indeed it has always be a bug, to reset the name to a different value.
The only valid place to set the name was in the _init() function of
the derived class itself.
This is now no longer needed/possible. Instead the name get's
detected based on the registered setting types. This makes use of
the registered metadata that is available anyway since every
usable setting has to register itself.
Signed-off-by: Thomas Haller <thaller@redhat.com>
It is better to leave it to user whether he wants to enable sending hostname,
because he probably disabled it manually (dhcp-send-hostname is TRUE by default).
Also, this would not work for plugins that read and set dhcp-hostname after
dhcp-send-hostname.
https://bugzilla.redhat.com/show_bug.cgi?id=1001529
Commit 6abc7b78f6 introduced a
bug in nm_connection_diff() by not reading the property value with
g_object_get_property().
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_connection_diff must also use the virtual functions like
nm_connection_compare. This way, settings can overwrite the default
comparison of individual properties.
Signed-off-by: Thomas Haller <thaller@redhat.com>
INFERRABLE means the opposite of CANDIDATE; a property which NetworkManager
can read ("infer") from the system or the kernel when generating
connections. CANDIDATE isn't a great name and thus dies.
This reverts commit f43586fc17.
This broke stuff as "name" was set on various places after construction. So we
revert the commit for now, and will rework it.
Make the name property CONSTRUCT_ONLY. With this there is also no more
need to overwrite the constructor().
Signed-off-by: Thomas Haller <thaller@redhat.com>
The public property is called NM_SETTING_VLAN_INTERFACE_NAME,
so also the internal field and the PROP_* enum should carry
the same name.
Signed-off-by: Thomas Haller <thaller@redhat.com>
These are (most likely) only warnings and not severe bugs.
Some of these changes are mostly made to get a clean run of
Coverity without any warnings.
Error found by running Coverity scan
https://bugzilla.redhat.com/show_bug.cgi?id=1025894
Co-Authored-By: Jiří Klimeš <jklimes@redhat.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
nm_connection_dump is mainly used for printf debugging, so
no need about being overly critical about not accepting NULL.
Just don't dump anything.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When settings are NULL or empty in impl_manager_add_and_activate_connection(),
the connection is created and completed by nm_utils_complete_generic() or
nm_device_complete_connection().
Also, do not assert in nm_connection_is_type(). Returning FALSE there is
sufficient.
Related commit a878cd8145
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>
Support new bonding options and set them carefully. The options cannot
be set arbitrarily because they interfere with each other.
This commit is forward-ported from rhel-6.5, see patch
rh901662-bond-more-options.patch, originally written by Dan Williams.
https://bugzilla.redhat.com/show_bug.cgi?id=901662https://bugzilla.redhat.com/show_bug.cgi?id=905532
Co-Authored-By: Dan Williams <dcbw@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.
