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)
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.
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.
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.
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
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)
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.
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.
