Just in case anyone uses this file as-is; I believe that these drivers don't need to be in a blacklist. There's a good chance they either work or we can detect failure to change a MAC address on runtime and act accordingly. Blacklisting the driver gives the driver maintainers no chance to fix the behavior and we are not able to log a warning on failure.
These are workarounds for Wi-Fi drivers. Don't set the unrelated "ethernet.cloned-mac-address" property.
These drivers work bad with changing the MAC address. See [1], [2], [3] for reports about failures with "wl" driver. [3] also blacklists driver "8188eu". While we already blacklist "r8188eu", it seems that some installations use the alternative name "8188eu" [4]. "wpasupplicant" package on Ubuntu 18.04 (bionic) provides the file "/usr/lib/NetworkManager/conf.d/no-mac-addr-change.conf", which blacklists the same drivers. See also bug [3] which added the file. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1695696 [2] https://bugzilla.gnome.org/show_bug.cgi?id=777523#c27 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833507 [4] https://github.com/lwfinger/rtl8188eu/blob/9a56f32c2a46be5b81f0eedf49ad44ea8f10bfae/dkms.conf
Codespel run with the same arguments as described in
commit 58510ed56679 ('docs: misc. typos pt2').
(cherry picked from commit bf0c4e6ac2855088e3962693886bb6ab71856f7b)
This is an API break since 1.16-rc1. Similar to previous commit. (cherry picked from commit 8ae9aa2428c10aafb837c692fb39bfd04ef4235c)
This is an API break since 1.16-rc1. Similar to previous commit. (cherry picked from commit 7962653918fbfd66b549d389a1cb2cf96ae0d3eb)
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 d7bc1750c1bcc5082528d1f277e09454b2cbf1c2)
When setting any secrets via D-Bus' Update2 call, then it assumes that all settings are reset. That means, when we modify any secrets in the client, we need to first load them all. Anyway, load always all secrets, then we can also print them in the get output. Honor WG_HIDE_KEYS like `wg` does. (cherry picked from commit 6aa9e52bd88670f10861e402a8c61c282a1e97c2)
(cherry picked from commit b5a458c5ffeec091cc60abbabaed4d1a49952872)
Use the script to test how GObject introspection with libnm's WireGuard support works. Also, since support for WireGuard peers is not yet implemented in nmcli (or other clients), this script is rather useful.