summaryrefslogtreecommitdiff
path: root/libnm-core
Commit message (Collapse)AuthorAgeFilesLines
* build: move "libnm-core/" to "src/" and split itThomas Haller2021-02-18188-108055/+0
| | | | | | | | | | | | | | | | | | | | "libnm-core/" is rather complicated. It provides a static library that is linked into libnm.so and NetworkManager. It also contains public headers (like "nm-setting.h") which are part of public libnm API. Then we have helper libraries ("libnm-core/nm-libnm-core-*/") which only rely on public API of libnm-core, but are themself static libraries that can be used by anybody who uses libnm-core. And "libnm-core/nm-libnm-core-intern" is used by libnm-core itself. Move "libnm-core/" to "src/". But also split it in different directories so that they have a clearer purpose. The goal is to have a flat directory hierarchy. The "src/libnm-core*/" directories correspond to the different modules (static libraries and set of headers that we have). We have different kinds of such modules because of how we combine various code together. The directory layout now reflects this.
* docs: improve manual page about ipv4.addressesWen Liang2021-02-171-0/+7
| | | | | | Signed-off-by: Wen Liang <liangwen12year@gmail.com> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/738
* shared: remove "str" argument from nm_str_buf_reset()Thomas Haller2021-02-111-1/+2
| | | | | | | NMStrBuf's API is all about convenience. When you reset the buffer, is it convenient to immediately append a new string? It seems not. Make nm_str_buf_reset() simpler by doing only one thing.
* setting-8021x: Fix descriptions for phase2-auth & phase2-autheapAndrew Zaborowski2021-02-091-11/+16
| | | | | | | | | | | | | | | phase2-auth applies for EAP-TTLS and EAP-PEAP but the interpretation is different for one than for the other, clarify the difference. phase2-auth is for the non-EAP inner methods of EAP-TTLS but is also for the EAP inner methods of EAP-PEAP. EAP-PEAP doesn't use phase2-autheap and doesn't support any non-EAP methods. Given how complicated EAP configuration is it's likely that people just use example configurations rather than look at the docs. The example configuration in man/nm-settings-keyfile.xsl is correct in using PEAP together with phase2-auth=mschapv2. [thaller@redhat.com: regenerate documentation files]
* libnm: move "nm-version-macros.h" from shared/ to libnm-core/Thomas Haller2021-02-092-0/+97
| | | | | | | | "nm-version-macros.h" is used directly by libnm-core and indirectly by libnm and core. Let's not have it randomly under shared/. Move it closer to where it's used.
* libnm: merge libnm-keyfile into libnm-coreThomas Haller2021-02-099-27/+6
| | | | | | | | | | | | | | | | | Before there was a licensing conflict between the keyfile code (libnm-keyfile) and libnm. The latter would require LGPL-2.1+ while keyfile code was GPL-2.0+. Consequently we were linking libnm-keyfile into the daemon, but not in libnm.so. This conflict has been resolved and keyfile API is part of libnm.so. There is no more need to build a separate (intermediary) library. Merge them. This also makes sense because keyfile code needs access to private code from libnm-core. It is closely tied to libnm-core, so that building them separate makes no sense (anymore).
* all: move shared/nm-meta-setting.[hc] to libnm-core and clientsThomas Haller2021-02-096-3/+841
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "shared/nm-meta-setting.[hc]" contains meta data about settings. As such it is similarly used by libnm-core (as internal API) and by clients (as extension of public API of libnm). However, it must be compiled twice, because while it defines in both cases a NMMetaSettingInfo type, these types are different between internal and public API. Hence, the files must also be compiled twice (and differently), once against libnm-core and once against the client helper library. Previously, the file was under "shared/", but there it's a bit odd it doesn't clearly belong anywhere. There are two goals here: - copy the file to the two places where it is used. We also have a "check-tree" unit test that ensures those files don't diverge in the future. - we no longer require CFLAGS set during built. Instead, the sources should control the build. For that we have new (simple) headers "nm-meta-setting-base.h" that define the right behavior for the impl files. There is still an ugliness (among several): the files must be named the same for libnm-core and clients/common. Preferably, all our sources have unique names, but that is not possible with this scheme (without introducing other ugliness). To mitigate that, include the files only at one exact place.
* all: add "libnm-core/nm-default-libnm-core.h" as replacement for "nm-default.h"Thomas Haller2021-02-0979-88/+105
|
* all: add "nm-glib-aux/nm-default-glib-i18n-lib.h" as replacement for ↵Thomas Haller2021-02-092-3/+2
| | | | "nm-default.h"
* libnm: compile keyfile code like libnm-coreThomas Haller2021-02-091-1/+1
| | | | | | | | By now, keyfile code got relicensed as LGPL-2.1+ and is just a regular part of libnm-core (in particular, because it uses private API of libnm-core). It should no longer be in a separate directory, but for now, at lead compile it the same as libnm-core.
* build: remove unused "nm-core-enum-types.[hc].template" filesThomas Haller2021-02-092-111/+0
|
* all: drop unnecessary cast of g_object_new()Thomas Haller2021-02-082-21/+21
| | | | | | | | | | | | Our cast macros (like NM_AUTH_SUBJECT()) are plain C pointer casts, unless when building with more asserts enabled. Still, they are unnecessary and even their ability to check the type (with more asserts) is not needed, because we must trust glib's g_object_new() to return reasonable objects. That is a basic requirement, that we don't need to assert against. Also, in the majority of cases we don't do this either.
* ethtool: add more offload features that kernel supportsThomas Haller2021-02-081-0/+5
| | | | | | | | | | | | | New features: - ethtool.feature-macsec-hw-offload - ethtool.feature-rx-gro-list - ethtool.feature-rx-udp-gro-forwarding - ethtool.feature-tls-hw-rx-offload - ethtool.feature-tx-gso-list - ethtool.feature-tx-tunnel-remcsum-segmentation https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/735
* doc: mention NETMASK as alternative to PREFIX for addresses in `man ↵Thomas Haller2021-02-081-1/+1
| | | | | | nm-settings-ifcfg-rh` https://bugzilla.redhat.com/show_bug.cgi?id=1925123
* libnm: fix NMVpnConnectionStateReason for glib-mkenumsThomas Haller2021-02-012-20/+53
| | | | | | | | | The previous form was confusing glib-mkenums parser. Simplify it. Fixes: 5022e3b8eea4 ('libnm: revert coercing NMVpnConnectionStateReason to NMActiveConnectionStateReason') https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/646
* build/meson: cleanup "libnm-core/tests/meson.build"Thomas Haller2021-01-271-20/+5
|
* build/meson: cleanup "libnm-core/meson.build"Thomas Haller2021-01-271-43/+39
|
* build/meson: rename "libnm_utils_base" to "libnm_glib_aux"Thomas Haller2021-01-271-5/+5
| | | | It's the better name.
* bond: introduce new 'vlan+srcmac' xmit_hash_policy optionAntonio Cardace2021-01-271-2/+2
| | | | | | | | | Kernel patch introducing this option: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=7b8fc0103bb5 https://bugzilla.redhat.com/show_bug.cgi?id=1915457 Signed-off-by: Antonio Cardace <acardace@redhat.com>
* libnm/docs: explain that edns0/trust-ad is automatically added to DNS optionsThomas Haller2021-01-261-0/+4
| | | | | | | Since commit f91a8ef3327a ('dns: add edns0 and trust-ad options when using local resolver') we automatically set these options. Document it.
* libnm: fix missing (allow-none) annotation for nm_setting_bond_validate_option()Thomas Haller2021-01-221-1/+1
|
* libnm/doc: consistently write "Since:" tag for enum valuesThomas Haller2021-01-203-11/+11
|
* all: change default value of hostname.only-from-default to falsebg/hostname-from-anyBeniamino Galvani2021-01-181-1/+1
| | | | | | | | | | | | | | | | | | | Currently, is retrieved by default only from the device with the default route. This is done so that in presence of multiple connections the choice is deterministic. However, this limitation seems confusing for users, that expect to get an hostname even for non-default devices. Change the default and allow any device to obtain the hostname. Note that when there is a default route, NM still prefers that device and so the behavior doesn't change. The only change in behavior is that when there is no default route and the machine doesn't have a static hostname, NM will try to get hostname from DHCP or reverse DNS. https://bugzilla.redhat.com/show_bug.cgi?id=1766944
* platform: use NMOptionBool instead of NMTernaryThomas Haller2021-01-152-4/+4
| | | | NMTernary is a dependency for libnm-core. Avoid it.
* shared: add NMOptionBool as alternative to NMTernaryThomas Haller2021-01-151-0/+18
| | | | | | | | | | | | NMTernary is part of libnm's public API. It thus cannot be used by code without libnm/libnm-core dependency. Add another enum with the same purpose. The name "NMTernary" is already taken, and we should not use some macro trickery to use (effectively) different types under the same name. Another possible name would be "NMTern", but for no strong reasons we choose NMOptionBool. The naming reminds of rust's std::option::Option.
* libnm,shared: move nm-ethtool helper to "libnm-base"Thomas Haller2021-01-159-427/+22
| | | | | | | | | | | | | | We want to use this by "shared/nm-platform", which should have no dependency on "libnm-core". Move "libnm-core/nm-ethtool-utils.h" to "libnm/nm-ethtool-utils.h" so that it is only used by libnm. This file contains the defines for the option names. Also, symlink "libnm/nm-ethtool-utils.h" as "shared/nm-base/nm-ethtool-utils-base.h". We want to use the same defines also internally. Since they are both public API (must be in libnm) and should be in "shared/nm-base", this is the way.
* libnm: split ethtool option names to a new header ↵Thomas Haller2021-01-157-92/+108
| | | | | | | | | | | | | | | "libnm-core/nm-ethtool-utils.h" We want to use these defines for option names also in "shared/nm-base" (and in turn in "shared/nm-platform), which cannot include "libnm-core". However, they are also public API of libnm. To get this done, in a first step, move these defines to a new header "libnm-core/nm-ethtool-utils.h". Since now the name "nm-ethtool-utils.h" is taken, also rename nm-libnm-core-intern files.
* shared: add duplicate for NM_UTILS_HWADDR_LEN_MAX to "nm-base/nm-base.h"Thomas Haller2021-01-151-0/+6
| | | | | We will need this in "shared/nm-platform", but we don't want to include "libnm-core/nm-utils.h" for that.
* platform: add duplicate of NMSettingWiredWakeOnLan to nm-base for platformThomas Haller2021-01-152-1/+69
| | | | | | | | | | | | | | | Currently src/platform depends on libnm-core. libnm-core is large optimally we have a better separation between our code. That means libnm-core does not depend on platform and vice versa. However, nm-platform re-uses some enums from libnm-core for internal code. To avoid that dependency, add _NMSettingWiredWakeOnLan as a duplicate to nm-base/nm-base.h. nm-base can both be used by libnm-core, nm-platform and src/platform. The only problem is that NMSettingWiredWakeOnLan is also part of public API of libnm. It means, we must duplicate the enum. But with several static assertions in unit tests I think that is not a problem to do.
* libnm: add "shared/nm-base/nm-base.h"Thomas Haller2021-01-151-129/+2
| | | | | | | | | | | | | | | | | | | | | | Our dependencies are complicated. Currently "src/platform" uses parts of libnm-core and is relatively strongly entangled with core. It would be nice to have that part clearly independent from "src" and from "libnm-core". Also, "src/platform/nm-platform-utils.h" uses NMEthtoolID enum, which previously was defined in "libnm-core/nm-libnm-core-intern/nm-ethtool-utils.h". Move that to a new place "shared/nm-base/nm-base.h". Note that we have "libnm-core/nm-libnm-core-intern", which is libnm/core related code which uses and is used by libnm-core. There is a need for a library which is used by libnm-core, but does not depend on libnm-core itself. Here comes "shared/nm-base". Yes, many libraries. But the goal is to entangle the dependencies and have a clear hierarchy of includes. And to have "shared/nm-platform" independent of libnm-core.
* core: move NM_MANAGER_ERROR to shared/nm-glib-auxThomas Haller2021-01-151-1/+0
| | | | | | | | "src/nm-logging.c" should be independent of libnm-core. It almost is, except the error domain and code. Move NM_MANAGER_ERROR to "nm-glib-aux/nm-shared-utils.h" so that "nm-logging.c" is independent of libnm-core.
* shared: add _nm_utils_hwaddr_aton_exact()Thomas Haller2021-01-151-11/+2
| | | | | | | | This is the same as libnm's nm_utils_hwaddr_aton(), which however is public API. We want to use this function also without libnm(-core). Hence add the helper to "shared/nm-glib-aux".
* shared: fix _nm_utils_enum_from_str_full() for negative enum valuesThomas Haller2021-01-151-0/+14
| | | | | | | Enums can also be negative (contrary to Flags). Fix the parsing. $ nmcli connection modify "$PROFILE" connection.llmnr -1 Error: failed to modify connection.llmnr: invalid option '-1', use one of [default,no,resolve,yes].
* libnm: avoid "-Wmaybe-uninitialized" warning in ↵Thomas Haller2021-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | | nm_setting_ethtool_get_optnames() With LTO build on s390x (Fedora 33) we get a compiler warning: libnm-core/nm-setting-ethtool.c: In function 'nm_setting_ethtool_get_optnames': libnm-core/nm-setting-ethtool.c:263:60: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized] 263 | return len > 0 ? nm_memdup(names, sizeof(names[0]) * (((gsize) len) + 1u)) : NULL; | ^ libnm-core/nm-setting-ethtool.c:257:24: note: 'len' was declared here 257 | guint len; | ^ libnm-core/nm-setting-ethtool.c: In function 'nm_setting_ethtool_get_optnames': libnm-core/nm-setting-ethtool.c:263:60: error: 'len' may be used uninitialized in this function [-Werror=maybe-uninitialized] 263 | return len > 0 ? nm_memdup(names, sizeof(names[0]) * (((gsize) len) + 1u)) : NULL; | ^ libnm-core/nm-setting-ethtool.c:257:24: note: 'len' was declared here 257 | guint len; | ^
* device: add "ipv4.dhcp-client-id=ipv6-duid" property for RFC4361Thomas Haller2021-01-111-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | RFC4361 intends to set the same IAID/DUID for both DHCPv4 and DHCPv6. Previously, we didn't have a mode for that. Of course, you could always set "ipv4.dhcp-client-id" and "ipv6.dhcp-duid" to (the same) hex string, but there was no automatic mode. Instead we had: - "ipv4.dhcp-client-id=duid" which sets the client ID to a stable, generated DUID. However, there was no option so that the same DUID/IAID would be automatically used for DHCPv6. - there are various special values for "ipv6.dhcp-duid" which generate a stable DUIDs. However, those values did not work for "ipv4.dhcp-client-id". Solve that by adding "ipv4.dhcp-client-id=ipv6-duid" which indicates to use the DUID from DHCPv6's "ipv6.dhcp-duid" setting. As IAID it will prefer "ipv4.dhcp-iaid" (if set), but fallback to "ipv6.dhcp-iaid". https://tools.ietf.org/html/rfc4361 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/618 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/718
* all: update deprecated SPDX license identifiersThomas Haller2021-01-05162-162/+162
| | | | | | | | | | | | | | | | These SPDX license identifiers are deprecated ([1]). Update them. [1] https://spdx.org/licenses/ sed \ -e '1 s%^/\* SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+ \*/$%/* SPDX-License-Identifier: \1-or-later */%' \ -e '1,2 s%^\(--\|#\|//\) SPDX-License-Identifier: \(GPL-2.0\|LGPL-2.1\)+$%\1 SPDX-License-Identifier: \2-or-later%' \ -i \ $(git grep -l SPDX-License-Identifier -- \ ':(exclude)shared/c-*/' \ ':(exclude)shared/n-*/' \ ':(exclude)shared/systemd/src' \ ':(exclude)src/systemd/src')
* libnm: fix style for SPDX License Identifer in "libnm-core/nm-keyfile.h"Thomas Haller2021-01-051-1/+1
|
* wifi: merge branch 'ac/wpa3eap_suiteb192'Antonio Cardace2020-12-224-34/+56
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/709
| * wifi: add WPA-EAP-SUITE-B-192 supportac/wpa3eap_suiteb192Antonio Cardace2020-12-224-34/+56
| | | | | | | | | | | | | | | | | | Add a new key management option to support WPA3 Enteprise wifi connection. Only supported with wpa_supplicant for the time being. Signed-off-by: Antonio Cardace <acardace@redhat.com>
* | libnm: allow opt-out of including system headers in <NetworkManager.h>Thomas Haller2020-12-222-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In public libnm headers we include some libc/linux headers, although libnm doesn't strictly need them. The <linux/*.h> headers conflict with some network headers provided by libc and they need to be included in the right order. As <NetworkManager.h> drags in some linux headers, this makes it unnecessarily complicated. It also feels ugly to include headers we don't need, only for the sake of convenience. Allow to opt out. Also, for internal build, don't do this. When building NetworkManager we need control about the headers and their order of inclusion.
* | libnm: avoid in_addr_t/in6addr use in libnm headerThomas Haller2020-12-221-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "in_addr_t" and "struct in6_addr" require headers from libc (or linux). In particular, some libc headers conflict with the linux headers (or they have to be included in a specific order). To avoid that we want that our libnm headers include a minimum of other headers (and only drag in glib headers, which we anyway need). - instead of "in_addr_t", use guint32. For all practical purposes, "in_addr_t" is a plain 32 bit integers and we can do this replacement in our public headers. - forward declare "struct in6_addr".
* | all: explicit include <linux/if_{ether,infiniband,vlan}.h> as neededThomas Haller2020-12-227-0/+10
|/ | | | | | | | | | | | | | Currently libnm headers include <linux/if_{ether,infiniband,vlan}.h>. These are public headers, that means we drag in the linux header to all users of <NetworkManager.h>. Often the linux headers work badly together with certain headers from libc. Depending on the libc version, you have to order linux headers in the right order with respect to libc headers. We should do better about libnm headers. As a first step, assume that the linux headers don't get included by libnm, and explicitly include them where they are needed.
* libnm: replace <netinet/ether.h> by <net/ethernet.h>/<net/if_arp.h> in ↵Thomas Haller2020-12-131-1/+2
| | | | | | | | | | "nm-utils.c" Including <netinet/ether.h> with musl leads to a conflict with <linux/if_ether.h>, due to redefining ethhdr struct. As we include <linux/if_ether.h> in "nm-utils.h", that is a problem. Avoid that, by including other headers.
* libnm: suppress "-Warray-bounds" warning in nm_team_link_watcher_new_ethtool()Thomas Haller2020-12-111-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gcc-11.0.0-0.7.fc34 warns here: CC libnm-core/libnm_core_la-nm-setting-team.lo libnm-core/nm-setting-team.c: In function ‘nm_team_link_watcher_new_ethtool’: libnm-core/nm-setting-team.c:127:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds] 127 | watcher->ref_count = 1; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~ libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’ 125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libnm-core/nm-setting-team.c:128:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds] 128 | watcher->type = LINK_WATCHER_ETHTOOL; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~ libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’ 125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libnm-core/nm-setting-team.c:129:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds] 129 | watcher->ethtool.delay_up = delay_up; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~ libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’ 125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ libnm-core/nm-setting-team.c:130:33: error: array subscript ‘NMTeamLinkWatcher[0]’ is partly outside array bounds of ‘unsigned char[16]’ [-Werror=array-bounds] 130 | watcher->ethtool.delay_down = delay_down; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~ libnm-core/nm-setting-team.c:125:15: note: referencing an object of size 16 allocated by ‘g_malloc’ 125 | watcher = g_malloc(nm_offsetofend(NMTeamLinkWatcher, ethtool)); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Maybe we should not use this trick and just malloc() a struct of the intended size, however: - the code below does a similar thing, doing it differently for ethtool watcher is confusing. - the NMTeamLinkWatcher is a union which cannot alter its type. In no case is it correct to access the fields of the wrong union type. By allocating a smaller chunk, valgrind might catch such bugs. Also, NMTeamLinkWatcher's definition is private to the C source file, in no case must anybody assume that the rest of the buffer actually exists. Hence, workaround the warning by suppressing it.
* libnm: allow OVS external-ids also for system interfaceThomas Haller2020-12-111-12/+27
| | | | | Note that reapply currently does not work for OVS system interface. That is, because the code does not make it easy to implement that.
* libnm: move detection/normalization of "connection.slave-type" to a separate ↵Thomas Haller2020-12-112-64/+104
| | | | | | | | | | | | function We allow normalizing the slave-type, but sometimes, we may want to validate a profile according to the set slave-type. For example, a "ovs-external-ids" setting should only be allowed for "connection.slave-type=ovs-interface". But during verify, the slave-type may be missing and not yet normalized. We need to be able to obtain the actually used slave-type.
* veth: add support to configure veth interfacesFernando Fernandez Mancera2020-11-276-0/+240
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NetworkManager is now able to configure veth interfaces throught the NMSettingVeth. Veth interfaces only have "peer" property. In order to support Veth interfaces in NetworkManager the design need to pass the following requirements: * Veth setting only has "peer" attribute. * Ethernet profiles must be applicable to Veth interfaces. * When creating a veth interface, the peer will be managed by NetworkManager but will not have a profile. * Veth connection can reapply only if the peer has not been modified. * In order to modify the veth peer, NetworkManager must deactivate the connection and create a new one with peer modified. In general, it should support the basis of veth interfaces but without breaking any existing feature or use case. The users that are using veth interfaces as ethernet should not notice anything changed unless they specified the veth peer setting. Creating a Veth interface in NetworkManager is useful even without the support for namespaces for some use cases, e.g "connecting one side of the veth to an OVS bridge and the other side to a Linux bridge" this is done when using OVN kubernetes [1][2]. In addition, it would provide persistent configuration and rollback support for Veth interfaces. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139 Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
* Revert "dns: change default DNS priority of VPNs to -50"Thomas Haller2020-11-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert this change. One problem is that none of the current GUIs (nm-connection-editor, gnome-control-center, plasma-nm) expose the dns-priority option. So, users tend to have their profile value set to 0. Changing the default means for them not only a change in behavior, but its hard to fix via the GUI. Also, what other call DNS leaks, is Split DNS to some. Both uses make sense, but have conflicting goals. The default cannot accommodate both at the same time. Also, with split DNS enabled (dnsmasq, systemd-resolved), the concern for DNS leaks is smaller. Imagine: Wi-Fi profile with ipv4.dns-priority (effectively) 100, domain "example.com". VPN profile with ipv4.dns-priority (effectively) 50 and a default route. That is a common setup that one gets by default (and what probably many users have today). In such a case with split DNS enabled, the Wi-Fi's DNS server only sees requests for "*.example.com". So, it does not leak everything. Hence, revert this change before 1.28.0 release to the earlier behavior. This reverts commit af13081bec8bf5cbe961df4c4577a7e4c7b14e97. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/688
* trivial: fix coding styleThomas Haller2020-11-201-1/+1
|
* libnm: improve error message of nm_keyfile_write() for invalid profilesThomas Haller2020-11-201-2/+27
|
View Lorry Controller Status