The interface-name property has several deprecated aliases, like
"bridge.interface-name". For backward compatibility, we keep handling
them.
In particular, the "missing_from_dbus_fcn" handler is set. This handles
the case where GVariant only contains the deprecated form, but not
"connection.interface-name".
Previously, from_dbus_fcn() would check whether the deprecated form was
present, and -- only if that form was invalid -- prefer it. The idea was
to fail validation if the deprecated property was invalid.
I think that is not necessary. Just completely ignore the deprecated property,
if the new property is present.
What might make sense is to check whether the deprecated and the new
form are both present, that they are identical. However, I don't think
that is worth the effort.
We use the filename of the imported .conf file for "connection.interface-name".
That follows what `wg-quick` does.
However, we also validate that the interface name is valid UTF-8
(otherwise -- as it currently is -- the setting couldn't be send via
D-Bus). As such, we have stricter requirements.
We want to fail early and tell the user when the filename is unsuitable.
Failing later gives a worse user experience, because the failure message
about invalid "connection.interface-name" wouldn't make it clear that
the filename is wrong.
Use the appropriate function to validate "connection.interface-name".
Before:
$ touch $'./a\344b.conf'
$ nmcli connection import type wireguard file $'./a\344b.conf'
Error: failed to import './a?b.conf': Failed to create WireGuard connection: connection.interface-name: 'a?b': interface name must be UTF-8 encoded.
Now:
$ nmcli connection import type wireguard file $'./a\344b.conf'
Error: failed to import './a?b.conf': The name of the WireGuard config must be a valid interface name followed by ".conf".
There should not be multiple places to validate the interface-name.
The check in "nm-setting-infiniband.c" is unnecessary and wrong.
It's unnecessary, because _nm_connection_verify() takes care to
first verify the NMSettingConnection instance.
It's wrong, because it does not check the property the same way as
NMSettingConnection does (e.g. it does not check for valid UTF-8).
Fully sort the settings in _nm_connection_verify(). Previously, only the
NMSettingConnection instance was sorted first (as required). The remaining
settings were in undefined order. That means, we would validate settings
in undefined order, and if multiple settings have an issue, the reported
error would be undefined.
Instead, use nm_connection_get_settings() which fully sorts the settings
(and of course, sorts NMSettingConnection first as we require it).
Also, this way we no longer need to allocate multiple GSList instances
but only malloc() one array large enough to contain all settings.
"all" and "default" never works.
"bonding_masters" works if you unload the bonding module. Well,
that should not really be called working...
Reject these names.
Generally, it's dangerous to reject values that were accepted
previously. This will lead to NetworkManager being unable to load
a profile from disk, which was loadable previously.
On the other hand, kernel would not have treated this setting as
it was intended. So, I would argue that the such a setting was not
working (as intended) anyway.
We can only hope that users don't configure arbitrary interface names.
It generally isn't a good idea to do, so "breaking" such things is less
of a concern.
It's very unlikely that we have actual blobs for a Wi-Fi network.
That is because the settings plugins (keyfile, ifcfg-rh) convert
blobs to files on disk when writing the profile. So, you can only
have them by editing the files directly to contain blobs.
At that point, don't always create the GHashTable for blobs.
Fail the enslavement of the ovs port if the bridge device is not
found, instead of generating assertions and potentially crash later.
https://bugzilla.redhat.com/show_bug.cgi?id=1797696
Fixes: 101e65d2bb ('ovs: allow changing mac address of bridges and interfaces')
The previous code tried to get the bridge active connection and it
used the port active connection instead in case of failure. This
doesn't seem right, as in nm-ovsdb.c the bridge AC is used to get the
bridge settings (including the uuid, interface name, and cloned mac).
In case of failure getting the bridge AC we should just fail.
Fixes: 830a5a14cb ('device: add support for OpenVSwitch devices')
Currently if an error is encountered during a send() of a message, the
client fails and there is no possibility of recover, since no timers
are armed after a failed event dispatch. An easy way to reproduce a
failure is to add a firewall rule like:
iptables -A OUTPUT -p udp --dport 67 -j REJECT
which makes the send() fail with EPERM during the renew. In such case,
the client should continue (failing) until it reaches the rebind phase
at T2, when it will be able to renew the lease using the packet
socket.
In general, a failure to send a packet should not cause the failure of
the client.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/419https://bugzilla.redhat.com/show_bug.cgi?id=1806516
To really use multiple NM_GOBJECT_PROPERTIES_DEFINE_BASE*() defines in
the same source file, several fixes to the suffix handling are
necessary. This fixes commit f13c7e3bbd ('shared: extend
NM_GOBJECT_PROPERTIES_DEFINE*() macros to append suffix to defined
names') to really work.
Fixes: f13c7e3bbd ('shared: extend NM_GOBJECT_PROPERTIES_DEFINE*() macros to append suffix to defined names')
Surisingly, the compiler may detect the remaining obj_type in
the default switch. Then, inlining nmp_class_from_type() it may detect
that this is only possible to hit with an out or range access to
_nmp_classes array.
Rework the code to avoid that compiler warning. It's either way not
supposed to happen.
Also, drop the default switch case and explicitly list the enum values.
Otherwise it is error prone to forget a switch case.
Clang 10 doesn't like NM_IN_SET() with strings and is right about that:
../libnm-core/tests/test-general.c:7763:9: error: result of comparison against a string literal is unspecified (use an explicit string comparison function instead) [-Werror,-Wstring-compare]
(void) NM_IN_SET ("a", "1", "2", "3", "4", "5", "6", "7", "8", "9", "10", "11", "12", "13", "14", "15", "16");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
However, NM_IN_STRSET() should work.
Otherwise, we get test failures with valgrind on fedora:rawhide
(valgrind-3.15.0-18.fc33.x86_64.rpm, gcc-10.0.1-0.8.fc33.x86_64,
glib2-devel-2.63.5-3.fc33.x86_64):
>>>> PRINT VALGRIND LOGS (valgrind test) (start)
+ find -name '*.valgrind-log' -print0
+ xargs -0 grep -H '^'
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- WARNING: unhandled amd64-linux syscall: 315
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- You may be able to write your own handler.
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- Nevertheless we consider this a bug. Please report
./src/devices/wwan/tests/test-service-providers.valgrind-log:--95634-- it at http://valgrind.org/support/bug_reports.html.
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- WARNING: unhandled amd64-linux syscall: 315
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- You may be able to write your own handler.
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- Nevertheless we consider this a bug. Please report
./libnm/tests/test-remote-settings-client.valgrind-log:--95245-- it at http://valgrind.org/support/bug_reports.html.
./libnm/tests/test-secret-agent.valgrind-log:--95280-- WARNING: unhandled amd64-linux syscall: 315
./libnm/tests/test-secret-agent.valgrind-log:--95280-- You may be able to write your own handler.
./libnm/tests/test-secret-agent.valgrind-log:--95280-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./libnm/tests/test-secret-agent.valgrind-log:--95280-- Nevertheless we consider this a bug. Please report
./libnm/tests/test-secret-agent.valgrind-log:--95280-- it at http://valgrind.org/support/bug_reports.html.
./libnm/tests/test-nm-client.valgrind-log:--95208-- WARNING: unhandled amd64-linux syscall: 315
./libnm/tests/test-nm-client.valgrind-log:--95208-- You may be able to write your own handler.
./libnm/tests/test-nm-client.valgrind-log:--95208-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
./libnm/tests/test-nm-client.valgrind-log:--95208-- Nevertheless we consider this a bug. Please report
./libnm/tests/test-nm-client.valgrind-log:--95208-- it at http://valgrind.org/support/bug_reports.html.
+ echo '>>>> PRINT VALGRIND LOGS (valgrind test) (done)'
>>>> PRINT VALGRIND LOGS (valgrind test) (done)
The advantage is that the API is now the same for IPv4 and IPv6: it's
all nm_dhcp_config_*() and we can (easier) treat the address family
generically.
We still need two distinct GObject types, mainly because of the
glue code for exposing the object on D-Bus as NMDBusObject. Of course,
that could be solved differently, but as it is, it's quite nice.
It would be better if we would be able to use NMLinkType enum
as an index (e.g. into an array of LinkDesc structures). For that,
it is necessary that the enum is just consecutive numbers.
Don't assign special meaning to the enum. Also, this was only
used at two places, that we can solve differently.
Seen on Debian 9, clang-3.8 (1:3.8.1-24):
../libnm-core/nm-setting-bond.c:596:49: error: comparison of constant 32 with expression of type 'NMBondMode' is always true [-Werror,-Wtautological-constant-out-of-range-compare]
nm_assert (_NM_INT_NOT_NEGATIVE (mode) && mode < 32);
~~~~ ^ ~~
This warning is not useful. While it may be implementation defined how enum
values outside the defined ones are handled, we commonly rely on placing
special numeric values in enums (e.g. ((NMEnumType) -1)).
An enum is (with our compilers) just a glorified integer, and there is nothing
preventing it from being outside the enum values. The warning is not helpful
and outright wrong. Disable it.
See-also: https://bugs.llvm.org//show_bug.cgi?id=16154
Fixes: 957bb2e111 ('libnm: use binary search for _nm_setting_bond_option_supported() implementation')
With `./configure --enable-more-asserts`, we add extra -W flags to
AM_CFLAGS. This variable is only used, if the per-library override
libnm_core_libnm_core_la_CFLAGS is unspecified ([1]).
Usually we avoid this problem be never specifying library_CFLAGS, but
placing all our per-library flags to library_CPPFLAGS. While that is a
bit of a hack and misuse of CPPFLAGS, it works well (enough).
This was broken recently. The effect was, that libnm-core was not
build with AM_CFLAGS flags. Fix it.
[1] https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html
Fixes: d2d6a68697 ('build: use -fcommon when building libnm-core')
verify() should validate options in a deterministic order, so that
the same profile (with same libnm version) gives the same failure
reason every time.
Hence, visit the options in sorted order, like we do for nm_setting_bond_get_option().
Internally, the options are tracked in a hash table and of undefined
sort order. However, nm_setting_bond_get_option() always returns a stable
(sorted) order.
Move "mode" as first, because that is usually the most interesting option.
The effect is:
$ nmcli -o connection show "$BOND_PROFILE"
...
-bond.options: arp_interval=5,arp_ip_target=192.168.7.7,arp_validate=active,mode=balance-rr,use_carrier=0
+bond.options: mode=balance-rr,arp_interval=5,arp_ip_target=192.168.7.7,arp_validate=active,use_carrier=0
This doesn't affect keyfile, which sorts the hash keys themself (and
doesn't treat the "mode" special).
This however does affect ifcfg-rh writer how it writes the BONDING_OPTS
variable. I think this change is fine and preferable.
