summaryrefslogtreecommitdiff
path: root/src/devices
Commit message (Collapse)AuthorAgeFilesLines
* all: move "src/" directory to "src/core/"Thomas Haller2021-02-04119-74124/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently "src/" mostly contains the source code of the daemon. I say mostly, because that is not true, there are also the device, settings, wwan, ppp plugins, the initrd generator, the pppd and dhcp helper, and probably more. Also we have source code under libnm-core/, libnm/, clients/, and shared/ directories. That is all confusing. We should have one "src" directory, that contains subdirectories. Those subdirectories should contain individual parts (libraries or applications), that possibly have dependencies on other subdirectories. There should be a flat hierarchy of directories under src/, which contains individual modules. As the name "src/" is already taken, that prevents any sensible restructuring of the code. As a first step, move "src/" to "src/core/". This gives space to reorganize the code better by moving individual components into "src/". For inspiration, look at systemd's "src/" directory. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/743
* udev/trivial: rename nm_udev_client_unref() to nm_udev_client_destory()Thomas Haller2021-02-031-1/+1
| | | | | | | | | | | | | | | | | | | | | NMUdevClient does not actually implement ref-counting, because it's not used. Still, the destroy function was named nm_udev_client_unref(), because theoretically then we could later, as the need arises, make the type ref-counted. Then unref function already had the right name. However, NMUdevClient also has a callback function that emits monitor events. Again for simplicity, this callback function cannot be reset, it can only be set once (in the constructor) and can also not be unset nor disabled. When the user of NMUdevClient is done with the instance and calls "unref", then it must be sure that the callback is no longer invoked afterwards. In practice that is already the case, but "unref" makes it sound as if somebody else could also still hold a reference -- in which case the user would have to first unset/disable the callback. Rename the function to "destroy()", so that it's clear that the instance is gone afterwards and that the callback will not be invoked anymore.
* all/udev: use NM_MAKE_STRV() for arguments of nm_udev_client_new()Thomas Haller2021-02-031-1/+1
|
* device: group boolean fields togetherBeniamino Galvani2021-02-031-10/+10
|
* device: fix bond-slave creation race-conditionAntonio Cardace2021-02-021-7/+42
| | | | | | | | | | | | | | In some cases the enslavement event of a device gets processed by nm-platform before the master NMDevice is created, in such cases the enslavement information is simply lost by NM, to prevent this let NMDevice connect to the 'device-ifindex-changed' signal to be notified of when its master NMDevice appears so that eventually the NMDevices will be consistent with the kernel network state. https://bugzilla.redhat.com/show_bug.cgi?id=1870691 Signed-off-by: Antonio Cardace <acardace@redhat.com>
* core: add 'device-ifindex-changed' signalAntonio Cardace2021-02-021-0/+2
| | | | | | | | | NMManager now emits a 'device-ifindex-changed' whenever a device ifindex gets changed. https://bugzilla.redhat.com/show_bug.cgi?id=1870691 Signed-off-by: Antonio Cardace <acardace@redhat.com>
* device: add 'master_ifindex' field to NMDeviceAntonio Cardace2021-02-021-0/+5
| | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1870691 Signed-off-by: Antonio Cardace <acardace@redhat.com>
* bond: release slaves prior to changing modeAntonio Cardace2021-02-022-1/+9
| | | | | | | | | | | | Bonds need to release all enslaved devices when the bond mode is to be changed. Also release slaves when they're external interfaces as it means the master it's now managed by NetworkManager. https://bugzilla.redhat.com/show_bug.cgi?id=1870691 Signed-off-by: Antonio Cardace <acardace@redhat.com>
* device: take over unmanaged devices when explicitely deactivatedAntonio Cardace2021-02-021-0/+6
| | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1870691 Signed-off-by: Antonio Cardace <acardace@redhat.com>
* device: make devices 'external' when going to 'unmanaged' stateAntonio Cardace2021-02-021-1/+1
| | | | | | | This is the default state for new devices hence they should return back to this state when unmanaged. Signed-off-by: Antonio Cardace <acardace@redhat.com>
* device: make 'nm_device_master_release_slaves' internal APIAntonio Cardace2021-02-022-1/+3
| | | | | | https://bugzilla.redhat.com/show_bug.cgi?id=1870691 Signed-off-by: Antonio Cardace <acardace@redhat.com>
* device: check ifindex before changing ethernet link settingsBeniamino Galvani2021-02-011-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | During the call to deactivate(), the device can already have lost the ifindex. Add a check for that to prevent assertion: ((src/platform/nm-platform.c:3306)): assertion 'g_return_val_if_fail(ifindex > 0, FALSE)' failed 0 g_logv (libglib-2.0.so.0 + 0x5bf67) 1 g_log (libglib-2.0.so.0 + 0x5c223) 2 _nm_g_return_if_fail_warning.lto_priv.0 (NetworkManager + 0x4c69f) 3 nm_platform_ethtool_set_link_settings (NetworkManager + 0x183418) 4 deactivate.lto_priv.1 (NetworkManager + 0x27dfd1) 5 nm_device_cleanup (NetworkManager + 0x25b047) 6 _set_state_full (NetworkManager + 0x24f4d8) 7 nm_device_unrealize (NetworkManager + 0x259e63) 8 _platform_link_cb_idle (NetworkManager + 0x27097f) 9 g_idle_dispatch (libglib-2.0.so.0 + 0x5305b) 10 g_main_context_dispatch (libglib-2.0.so.0 + 0x53f8f) 11 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa74d8) 12 g_main_loop_run (libglib-2.0.so.0 + 0x53673) 13 main (NetworkManager + 0x4bdba) 14 __libc_start_main (libc.so.6 + 0x27b75) 15 _start (NetworkManager + 0x4c3ee) https://bugzilla.redhat.com/show_bug.cgi?id=1923062
* build/meson: fix linking of core plugins to not include static helper librariesThomas Haller2021-01-286-9/+11
| | | | | | | | | | | | | | | | | | | | | We have many static helper libraries, like libnm-glib-aux or libnm-core. These can be statically linked in any end-binary as internal API. However, they must only be linked once. Also, we have various plugins (device, settings, ppp, wwan) which are dlopened by NetworkManager. They should use the symbols from NetworkManager core. It is important that they do not link with the static libraries already, because also NetworkManager core links with it, so these symbols will be duplicate. As the symbols are internal, you might think that it is not a real problem to duplicate them. However, there are also global variables, like the hash tables for NMRefStr or the seed for NMHash. These global variables must be only be used once, and hence also these symbols must no be duplicated. Fix that by adding a new dependency that is for the core plugins. This dependency only has "include_directories" but not "link_with".
* build/meson: cleanup meson files of coreThomas Haller2021-01-286-106/+108
|
* build/meson: rename "daemon_nm_default_dep" to "core_default_dep"Thomas Haller2021-01-286-7/+7
| | | | | | | | Naming for us is hard, because everything is an "nm". However, let's standardize on the term "core" for the daemon, and not "daemon". Eventually I would like to move the daemon from "src/" to "src/core/", rename the dep in anticipation of that.
* build/meson: cleanup "src/meson.build"Thomas Haller2021-01-274-4/+4
|
* core: unblock OVS interfaces when the ovsdb is readyBeniamino Galvani2021-01-271-0/+2
| | | | | | | | | | | | OVS system interfaces can start to connect even before the ovsdb is ready. However, the connection attempt is doomed to fail and the NMSettingsConnection gets blocked with reason FAILED. Unblock them once the ovsdb is ready. Ideally, NMPolicy should subscribe to the NMOvsdb::ready signal, however NMOvsdb is in a plugin, so it's easier if NMOvsdb directly calls a function of the core.
* ovs: set OVS interfaces as available only after ovs-ready signalBeniamino Galvani2021-01-271-4/+47
| | | | | | Don't allow OVS interfaces to connect until the NMOvsdb signals it's ready. Otherwise, connection attemps can race with the initial OVS cleanup.
* ovs: improve disconnecting devices after removal from ovsdbBeniamino Galvani2021-01-271-1/+1
| | | | | | | | | | | | | Sometimes during boot the device starts an activation with reason 'assumed', then the ovs interfaces gets removed from the ovsdb. At this point the device has an active-connection associated; it has the activate_stage1_device_prepare() activation source scheduled, but it is still in disconnected state. Currently the factory doesn't recognizes that the device is activating and allows the device to proceed even if the interface was removed from the ovsdb. Fix this by checking the presence of an active-connection instead.
* ovs: clean up interfaces from ovsdb at startupBeniamino Galvani2021-01-272-1/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | During shutdown, NM always tries to remove from ovsdb all bridges, ports, interfaces that it previously added. Currently NM doesn't run the main loop during shutdown and so it's not possible to perform asynchronous operations. In particular, the NMOvsdb singleton is disposed in a destructor where it's not possible to send out all the queued deletions. The result is that NM deletes only one OVS interface, keeping the others. This needs to be fixed, but requires a rework of the shutdown procedure that involves many parts of NM. Even when a better shutdown procedure will be implemented, we should support an unclean shutdown caused by e.g. a kernel panic or a NM crash. In these cases, the interfaces added by NM would still linger in the ovsdb. Delete all those interface at NM startup. If there are connections profiles for them, NM will create them again. Also, NMOvsdb now emits a NM_OVSDB_READY signal and provides a nm_ovsdb_is_ready() to allow other parts of the daemon to order actions after the initial OVS cleanup. https://bugzilla.redhat.com/show_bug.cgi?id=1861296 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/700
* ovs: change reason for deactivation-on-removalBeniamino Galvani2021-01-271-1/+1
| | | | | The interface was removed, so NM_DEVICE_STATE_REASON_REMOVED sounds more correct.
* ovs: fail OVS system interfaces when the db entry gets removedBeniamino Galvani2021-01-271-4/+32
| | | | | | | | | | If an OVS system interface that is active in NM gets removed externally from the ovsdb, NM doesn't notice it and keeps the connection active. Let the OVS factory also handle the removal message for system interfaces. In that case, we need to match the removed interface name to the actual device, which can be of any kind.
* ovs: rework emitting signals for new/removed devicesBeniamino Galvani2021-01-272-36/+57
| | | | | Instead of filtering the signals in NMOvsdb, emit them all and let the subscriber decide what to do with them.
* ovs: let the factory create devices for external patch interfacesBeniamino Galvani2021-01-271-1/+1
| | | | | Patch interfaces are conceptually similar to internal interfaces. Let the factory create devices for patch interfaces created externally.
* ndisc: track expiry of Router Advertisements in millisecondsThomas Haller2021-01-271-36/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Elements of RAs have a lifetime. Previously we would track both the timestamp (when we received the RA) and the lifetime. However, we are mainly interested in the expiry time. So tracking the expiry in form of timestamp and lifetime is redundant and cumbersome to use. Consider also the cases nm_ndisc_add_address() were we mangle the expiry. In that case, the timestamp becomes meaningless or it's not clear what the timestamp should be. Also, there are no real cases where we actually need the receive timestamp. Note that when we convert the times to NMPlatformIP6Address, we again need to synthesize a base time stamp. But here too, it's NMPlatformIP6Address fault of doing this pointless split of timestamp and lifetime. While at it, increase the precision to milliseconds. As we receive lifetimes with seconds precision, one might think that seconds precision is enough for tracking the timeouts. However it just leads to ugly uncertainty about rounding, when we can track times with sufficient precision without downside. For example, before configuring an address in kernel, we also need to calculate a remaining lifetime with a lower precision. By having the exact values, we can do so more accurately. At least, in theory. Of course NMPlatformIP6Address itself has only precision of seconds, we already loose the information before. However, NMNDisc no longer has that problem.
* device: fix assertion failure when resolving hostnameBeniamino Galvani2021-01-201-0/+5
| | | | | | | | | | | nm_device_get_effective_ip_config_method() must called only on a device with an applied connection. Fix assertion failure [1]: nm_device_get_effective_ip_config_method: assertion 'NM_IS_CONNECTION(connection)' failed [1] http://faf.lab.eng.brq.redhat.com/faf/reports/20217/ Fixes: 09c83871144a ('policy: use the hostname setting'):
* device: if a device is not IFF_UP assume that is has carrierThomas Haller2021-01-191-0/+9
| | | | | | | | | | | | | | A device that is not IFF_UP does not have carrier. So we don't know the real state before we bring it up. On the other hand, during `nmcli connection up` we check whether the device is available. So we are blocked. The solution is to optimistically assume that the device has carrier if it is down. We may fail later. $ nmcli connection add type veth con-name vv0 autoconnect no ifname vv0 peer vv1 ipv4.method shared ipv6.method shared $ nmcli connection up vv0 $ nmcli device connect vv1 Error: Failed to add/activate new connection: Connection 'vv1' is not available on device vv1 because device has no carrier
* device: fix complete-connection for veth devicesThomas Haller2021-01-192-29/+54
| | | | | | | | | | | | | | | | Otherwise, $ nmcli device connect veth0 fails with Error: Failed to add/activate new connection: veth.peer: property is not specified In complete_connection(), we should by default complete ethernet connections, unless the caller already indicated to want a veth profile. Fixes: cd0cf9229d49 ('veth: add support to configure veth interfaces')
* device: fix stale pointer in nm_device_get_hostname_from_dns_lookup()Beniamino Galvani2021-01-191-1/+1
| | | | | | Fixes: 09c83871144a ('policy: use the hostname setting') https://bugzilla.redhat.com/show_bug.cgi?id=1917713
* wifi: log WPS flag of access pointThomas Haller2021-01-181-1/+5
|
* platform: move "nm-platform-utils.[hc]" to "shared/nm-platform" libraryThomas Haller2021-01-152-2/+2
| | | | | By now it has no further dependencies on libnm-core or NetworkManager core. Make it part of "shared/nm-platform" library.
* platform: use NMOptionBool instead of NMTernaryThomas Haller2021-01-151-11/+12
| | | | NMTernary is a dependency for libnm-core. Avoid it.
* libnm,shared: move nm-ethtool helper to "libnm-base"Thomas Haller2021-01-151-1/+1
| | | | | | | | | | | | | | 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-151-1/+1
| | | | | | | | | | | | | | | "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.
* platform: add duplicate of NMSettingWiredWakeOnLan to nm-base for platformThomas Haller2021-01-151-1/+1
| | | | | | | | | | | | | | | 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.
* core/logging: move "nm-logging.c" to shared/nm-log-core/libnm-log-core libraryThomas Haller2021-01-151-1/+0
| | | | | | | | | We want to move platform code to "shared/nm-platform". However, platform code uses the logging infrastructure from the daemon, there is thus an odd circular dependency. Solve that by moving the "src/nm-logging.[hc]" to a new helper library in "shared/nm-log-core".
* devices/tests: improve assert for ioctl() in _test_recv_fixture_setup()Thomas Haller2021-01-141-2/+11
| | | | | | | | | This assert sometimes fails during copr builds. But the way the assert was, it was hard to see what the actual problem was. Restructure the assert (again) to get the errno in the test logs.
* wireguard: delay activation while resolving DNS names for WireGuard peers to ↵Thomas Haller2021-01-141-21/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | avoid race The endpoints of WireGuard peers can be configured as DNS name, which NetworkManager will resolve. Since activating a profile might affect now names get resolved, we must first resolve names before completing the activation of the WireGuard device (and before reconfiguring DNS accordingly). For example, if you configure exclusive DNS resolution via the WireGuard device, and if the peer needs to be resolved via DNS, then resolving the peer name must happen before the reconfiguration of DNS. Otherwise the new DNS configuration will be broken due to being unable to reach the WireGuard peer. Fix that by waiting. There is still an unfixed problem. If resolving any peers fails, activation silently proceeds -- again possibly breaking the network setup. Of course, NetworkManager will repeatedly try to re-resolve the name, but that may never succeed if DNS would be resolved via the VPN itself. That is different from `wg set` which resolves hostnames and fails. Consequently `wg-quick up` would also fail. But these are both one shot applications, they are not around and basically let the user handle the error (by reading the log and invoking the command again). NetworkManager can do something different and proceed activation (as it will also periodically re-resolve the hostnames again). Note that it's also valid to activate a WireGuard device without any peers (and to modify the activated device later with Reapply()). As such, having no peers (or being unable to resolve a hostname) may be a valid configuration. I think we should add an option/flag that when enabled will cause the activation to fail of names cannot be resolved. https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/535 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/616 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/721
* core: avoid "-Wmaybe-uninitalized" warning in link_negotiation_set()Thomas Haller2021-01-141-3/+3
| | | | | | | | | | | With LTO and gcc-10.2.1-9.fc33.s390x we get: src/platform/nm-platform.c:3325:1: error: link_duplex may be used uninitialized in this function [-Werror=maybe-uninitialized] 3325 | NM_UTILS_LOOKUP_STR_DEFINE(nm_platform_link_duplex_type_to_string, | ^ src/devices/nm-device-ethernet.c:899: note: link_duplex was declared here 899 | NMPlatformLinkDuplexType link_duplex; |
* device: clean up dispatcher calls when canceling an activationbg/rh1888348Beniamino Galvani2021-01-141-0/+1
| | | | | | | | Ensure the callback for dispatcher calls is not executed, or it will resume the activation chain we want to interrupt. https://bugzilla.redhat.com/show_bug.cgi?id=1888348 https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/723
* device: set out-argument to nm_device_get_permanent_hw_address_full() in ↵Thomas Haller2021-01-131-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | assertion case When compiling with LTO, the compiler can think that an assertion failure (g_return*()) is regular code path, and thus that the output variable is not set. This can lead to "-Wmaybe-uninitialized" warnings in the caller, despite this not happening in non-bug case. Work aound that by setting the out argument. Warning with LTO enabled and gcc-10.2.1-9.fc33.s390x: src/nm-config-data.c: In function nm_config_data_get_device_config: src/devices/nm-device.c:17454:9: error: is_fake may be used uninitialized in this function [-Werror=maybe-uninitialized] 17454 | m = nm_match_spec_device(specs, | ^ src/devices/nm-device.c:17444:26: note: is_fake was declared here 17444 | gboolean is_fake; | ^ src/nm-config-data.c: In function nm_config_data_get_connection_default: src/devices/nm-device.c:17454:9: error: is_fake may be used uninitialized in this function [-Werror=maybe-uninitialized] 17454 | m = nm_match_spec_device(specs, | ^ src/devices/nm-device.c:17444:26: note: is_fake was declared here 17444 | gboolean is_fake; | ^ src/devices/nm-device.c: In function nm_device_check_unrealized_device_managed: src/devices/nm-device.c:17454:9: error: is_fake may be used uninitialized in this function [-Werror=maybe-uninitialized] 17454 | m = nm_match_spec_device(specs, | ^
* lldp/tests: make assertion in _test_recv_fixture_setup() clearerThomas Haller2021-01-121-1/+4
| | | | ... to print the errno value on failure.
* core: avoid "-Wmaybe-uninitialized" warning in lldp_neighbor_get_raw()Thomas Haller2021-01-121-2/+2
| | | | | | | | | | | | | | | | src/devices/nm-lldp-listener.c: In function 'lldp_neighbor_to_variant': ./shared/nm-glib-aux/nm-shared-utils.h:1271:5: error: 'raw_len' may be used uninitialized in this function [-Werror=maybe-uninitialized] 1271 | g_variant_builder_add(builder, | ^ src/devices/nm-lldp-listener.c:107:19: note: 'raw_len' was declared here 107 | gsize raw_len; | ^ ./shared/nm-glib-aux/nm-shared-utils.h:1271:5: error: 'raw_data' may be used uninitialized in this function [-Werror=maybe-uninitialized] 1271 | g_variant_builder_add(builder, | ^ src/devices/nm-lldp-listener.c:106:19: note: 'raw_data' was declared here 106 | gconstpointer raw_data; | ^
* device: add "ipv4.dhcp-client-id=ipv6-duid" property for RFC4361Thomas Haller2021-01-111-17/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-05117-117/+117
| | | | | | | | | | | | | | | | 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')
* all: adjust imports to fix libc/linux headersThomas Haller2020-12-232-2/+4
| | | | | | | | | | | | | | | | Linux headers and some libc headers have overlapping defines for network types and functions. In the past years, glibc and linux headers were improved to cooperate so you could include either one, in any order. With musl and possibly some older glibc versions that doesn't work so well. Reorder and change includes to make it work better. Yes, this looks pretty random and unmotivated. The includes are changed in order to successfully build on various libc/kernel versions, with the goal of not using #if.
* wifi: merge branch 'ac/wpa3eap_suiteb192'Antonio Cardace2020-12-222-5/+14
|\ | | | | | | https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/709
| * wifi: add WPA-EAP-SUITE-B-192 supportac/wpa3eap_suiteb192Antonio Cardace2020-12-222-5/+14
| | | | | | | | | | | | | | | | | | 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>
* | all: explicit include <linux/if_{ether,infiniband,vlan}.h> as neededThomas Haller2020-12-2213-0/+17
|/ | | | | | | | | | | | | | 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.
* ovs: fix indentationBeniamino Galvani2020-12-181-2/+1
| | | | Fixes: ec7d8ddb295b ('ovs: fix leaks')
View Lorry Controller Status