On Fedora rawhide we get the following build failure:
In file included from shared/systemd/src/basic/alloc-util.c:3:
./shared/systemd/sd-adapt-shared/nm-sd-adapt-shared.h:114:21: error: static declaration of 'gettid' follows non-static declaration
114 | static inline pid_t gettid(void) {
| ^~~~~~
In file included from /usr/include/unistd.h:1170,
from /usr/include/glib-2.0/gio/gcredentials.h:32,
from /usr/include/glib-2.0/gio/gio.h:46,
from ./shared/nm-utils/nm-macros-internal.h:31,
from ./shared/nm-default.h:293,
from ./shared/systemd/sd-adapt-shared/nm-sd-adapt-shared.h:22,
from shared/systemd/src/basic/alloc-util.c:3:
/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' was here
34 | extern __pid_t gettid (void) __THROW;
| ^~~~~~
glibc supports now gettid() call ([1]) which conflicts with our compat
implementation. Rename it.
[1] https://sourceware.org/git/?p=glibc.git;a=commit;h=1d0fc213824eaa2a8f8c4385daaa698ee8fb7c92
(cherry picked from commit 10276322bd)
Using test-networkmanager-servic.py, I get the following error when
trying to add manual config with a dns address:
Error: g-io-error-quark: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 707, in _message_cb
retval = candidate_method(self, *args, **keywords)
File "tools/test-networkmanager-service.py", line 1727, in AddConnection
return self.add_connection(con_hash)
File "tools/test-networkmanager-service.py", line 1731, in add_connection
con_inst = Connection(self.c_counter, con_hash, do_verify_strict)
File "tools/test-networkmanager-service.py", line 1601, in __init__
NmUtil.con_hash_verify(con_hash, do_verify_strict=do_verify_strict)
File "tools/test-networkmanager-service.py", line 497, in con_hash_verify
BusErr.raise_nmerror(e)
File "tools/test-networkmanager-service.py", line 419, in raise_nmerror
raise e
Exception: Unsupported value ipv4.dns = dbus.Array([dbus.UInt32(168430090L), dbus.UInt32(218893066L)], signature=dbus.Signature('u'), variant_level=1) (Cannot convert array element to type 'u': Must be number, not Variant)
https://mail.gnome.org/archives/networkmanager-list/2019-March/msg00013.html
(cherry picked from commit 9a71d7d273)
When the link goes down the kernel removes IPv6 addresses from the
interface. In update_ext_ip_config() we detect that addresses were
removed externally and drop them from various internal
configurations. Don't do that if the link is down so that those
addresses will be restored again on link up.
(cherry picked from commit 505d2adbc2)
Add a new argument to nm_ip_config_* helpers to also ignore addresses
similarly to what we already do for routes. This will be used in the
next commit; no change in behavior here.
(cherry picked from commit 39b7257208)
We can detect false DAD failures if the link goes down. Don't try to
prevent them, but just reset the counter if the link goes down.
(cherry picked from commit 056470a4ba)
When the interface is down DAD failures becomes irrelevant and we
shouldn't try to add a link-local address even if the configuration
contains other IPv6 addresses.
(cherry picked from commit 72385f363c)
nm_device_get_device_type would report the device type as it was send on
DBus, while fetching the property would mean that only a known device
types is reported.
Make both results consistent by coercing in nm_device_get_device_type
rather than when setting the property.
(cherry picked from commit a6a185ba00)
The device type was set to the GType rather than a new value in the
NMDeviceType enum.
Add the corresponding enum entry, fix the device type and set the
routing priority to the same value as generic devices.
(cherry picked from commit 8d9365a973)
Support importing ".conf" files as `wg-quick up` supports it.
`wg-quick` parses several options under "[Interface]" and
passes the remainder to `wg setconf`.
The PreUp/PreDown/PostUp/PostDown options are of course not supported.
"Table" for the moment behaves different.
(cherry picked from commit a3a8583c31)
A NetworkManager client requires an API to validate and decode
a base64 secret -- like it is used by WireGuard. If we don't have
this as part of the API, it's inconvenient. Expose it.
Rename it from _nm_utils_wireguard_decode_key(), to give it a more
general name.
Also, rename _nm_utils_wireguard_normalize_key() to
nm_utils_base64secret_normalize(). But this one we keep as internal
API. The user will care more about validating and decoding the base64
key. To convert the key back to base64, we don't need a public API in
libnm.
This is another ABI change since 1.16-rc1.
(cherry picked from commit e46ba01867)
According to documentation, this returns a boolean indicating whether
the value is valid. Previously, it was indicating whether the instance
was modified.
Together with the @accept_invalid argument, both behaviors make some
sense. Change it, because that is also how the other setters behave.
(cherry picked from commit f3ac8c6fe8)
This is an API break since 1.16-rc1.
The functions like _nm_utils_wireguard_decode_key() are internal API
and not accessible to a libnm user. Maybe this should be public API,
but for now it is not.
That makes it cumbersome for a client to validate the setting. The client
could only reimplement the validation (bad) or go ahead and set invalid
value.
When setting an invalid value, the user can afterwards detect it via
nm_wireguard_peer_is_valid(), but at that point, it's not clear which
exact property is invalid.
First I wanted to keep the API conservative and not promissing too much.
For example, not promising to do any validation when setting the key.
However, libnm indeed validates the key at the time of setting it
instead of doing lazy validation later. This makes sense, so we can
keep this promise and just expose the validation result to the caller.
Another downside of this is that the API just got more complicated.
But it not provides a validation API, that we previously did not have.
(cherry picked from commit d7bc1750c1)
If we already specified "type" or "file", don't offer it for
completion again.
$ nmcli connection import type openvpn <TAB>
file type
(cherry picked from commit fea0f4a5ea)
[thaller@redhat.com: the code is effectively key_is_zero() by
<Jason@zx2c4.com> (LGPL2.1+). I took it into our source tree
and adjusted it to our style]
(cherry picked from commit 6234e41153)
- For PSK, an all-zero PSK means to don't do symmetric encryption. As such,
at first it seems a bit odd when the user sets
- preshared-key-flags != "4 (not-required)"
- preshared-key = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
Here the user indicates that a PSK is required, but then provides an
all-zero PSK that effectively disables it. Still, we should not reject
such a configuration. This has the benefit that it allos the user for
being prompted for a PSK, only to disable it by entering the all-zero key.
- For the private-key (and consequently the public-key), "public-key-flags=4"
is rejected by libnm. A private key is always required for NetworkManager to
configure the link. However, let's not care for all-zero keys either. If the user
configures that, we just set that key. It's a valid setting as far as WireGuard
(the kernel module) is concerned, so we shouldn't reject it.
(cherry picked from commit 78dccb8bb9)
In newer RPM file triggers in glibc package take care of this. While
these scriptlets whould do no harm there, removing them yields a tiny
theoretical performance improvement.
(cherry picked from commit a1e6afc0b2)
This is utterly pointless. %ldconfig_scriptlets expand to an empty
string on Fedora 28+.
This reverts commit ad836541cb.
(cherry picked from commit 3326a87953)
Group tag is not required, though is harmless. We could either remove it,
or keep it, but there's absolutely no excuse for conditionalizing it.
Let's keep it for now, because rpm -i still prints it.
This reverts commit 1feeba6f1a.
(cherry picked from commit 27418b1851)
The condition got accidentally reversed, which means we're always
undecided and thus wrongly assuming support and never being able to set
any addresses.
This would bother the few that are struck with 3.4 android kernels. Very
few indeed, given this got unnoticed since 1.10.
Fixes: 8670aacc7c ('platform: cleanup detecting kernel support for IFA_FLAGS and IPv6LL')
(cherry picked from commit d551a0893e)
The "vala-tools" package was merged into "vala" [1]. While "vala"
now "Provides: vala-tools", update the build requirements for
Fedora 30 and newer.
[1] 82b21cc302f6c878a04a
(cherry picked from commit 0024485b5a)
Fix the following failed assertion:
<debug> device[0x11dfec0] (p2p-dev-wlp4s0): P2P: Releasing WPA supplicant interface.
<debug> supplicant: setting WFD IEs for P2P operation
(../src/devices/nm-device.c:14769):_set_state_full: runtime check failed: (priv->in_state_changed == FALSE)
<info> device (p2p-dev-wlp4s0): state change: unmanaged -> unavailable (reason 'supplicant-failed', sys-iface-state: 'external')
<debug> device[0x11dfec0] (p2p-dev-wlp4s0): add_pending_action (1): 'waiting-for-supplicant'
supplicant_interfaces_release() can be called during a state change
(for example by device_state_changed()) and so it can't trigger
another state change.
nm_device_wifi_p2p_set_mgmt_iface() now doesn't force an immediate
state change and only schedules a recheck-available. This means that
the device can be in an available state without
priv->mgmt_iface. Adapt the code to deal gracefully with that
situation. In particular, we need to cancel pending timeout sources
(priv->sup_timeout_id) that use the management interface.
Fixes: 27bc2cb22ahttps://github.com/NetworkManager/NetworkManager/pull/302
(cherry picked from commit d2e95856e9)
